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ABSTRACT 


There is currently a very strong interest among researchers in the fields of artificial 
intelligence and robotics in finding more effective means of linking high level symbolic 
computations relating to mission planning and control for autonomous vehicles to low level vehicle 
control software. The diversity exhibited by the many processes involved in such control has 
resulted in a number of proposals for a general software architecture intended to provide an 
efficient yet flexible framework for the organization and interaction of relevant software 
components. The Rational Behavior Model (RBM) has been developed with these requirements in 
mind and consists of three levels, called the Strategic, the Tactical, and the Execution levels, 
respectively. Each level reflects computations supporting the solution to the global control problem 
based on different abstraction mechanisms. The unique contribution of the RBM architecture is the 
idea of specifying different programming paradigms to realize each software level. Specifically, 
RBM uses rule-based programming for the Strategic level, thereby permitting field reconfiguration 
of missions by a mission specialist without reprogramming at lower levels. The Tactical level 
realizes vehicle behaviors as the methods of software objects programmed in an object-based 
language such as Ada. These behaviors are initiated by rule satisfaction at the Strategic level, 
thereby rationalizing their interaction. The Execution level is programmed in any imperative 
language capable of supporting efficient execution of real-time control of the underlying vehicle 
hardware. The viability of this architecture has been established through computer simulation 
studies of control of an autonomous submarine, the NFS Autonomous Underwater Vehicle. These 
experiments have confirmed that the RBM architecture provides important advantages in terms of 
program conciseness, maintainability, reliability, and modifiability. In addition, by constraining 
the interfaces between the levels and limiting the accessibility of state variables, the team 
development of autonomous vehicle control software is significantly enhanced. 
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L INTRODUCTION 


A. BACKGROUND 

There is no question that advances in VLSI circuitry design, processor speed and ca¬ 
pabilities, and hardware miniaturization have revolutionized the field of autonomous mo¬ 
bile robots [Ref. 1]. These breakthroughs have led naturally to increasingly sophisticated 
and complex requirements by the end users of robotic systems, and these same users have 
grown to expect finished products which satisfy these requirements. It follows that users 
are identifying applications where fully autonomous robots would be advantageous, either 
by removing the human element from a dangerous or undesirable work environment or by 
extending the capability of humans into a new domain. Scenarios in which autonomous ro¬ 
bots perform these duties have existed only in the realm of science fiction up to now; how¬ 
ever, the technological advances of the past decade have placed us in a position where re¬ 
alization of such robots are not only possible but inevitable [Ref. 2]. 

However, there are many issues yet to be addressed. It is one thing to design and build 
the physical robot, and quite another to imbue the robot with the desired degree of intelli¬ 
gence, Experience and expertise in these areas have been accumulating for many decades 
and is now generally associated with the scientific field of robotics. Control of the hard¬ 
ware, including motors, arms, and actuators, is relatively well understood and is usually 
discussed in the context of feedback control theory [Ref. 3]. This theory is, after all, found¬ 
ed upon the fundamental tenets of mathematics, physics, and engineering. Feedback (or 
servo) control is ideal when applied to systems, robotic or otherwise, that perform either 
regulation (disturbance rejection) or command tracking tasks. Examples include position 
control of manipulator arms associated with industrial robots employed for the assembly of 
components. In most cases, the “problem” being solved has been subjected to extensive 
study. Every detail has been identified, analyzed, and programmed from a formal, mathe- 
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matical perspective. The robot’s work cell [Ref. 4], or environment, is also rigorously mod¬ 
eled. The goal of these efforts is to minimize uncertainty and risk by expressing the robot’s 
world and its interaction with that world in unambiguous terms. 

Research in the field of robotics goes well beyond servo control, however. Concepts 
from artificial intelligence, computer vision, vehicle navigation, and graph theory are uti¬ 
lized to implement compiled human knowledge as applied to the problems of motion, path 
planning, and object identification and avoidance [Ref. 5]. Even so, there are many appli¬ 
cations where fully autonomous robots would be desirable but which cannot be described 
mathematically, or circumstances where all possible situations cannot be anticipated. The 
related tasks will, as a result, be complex and wrought with uncertainty. In these circum¬ 
stances, the static nature of the assumptions pertaining to the environment of the robot will 
no longer hold, and systems based on these assumptions can no longer be relied upon to 
perform as expected. Attempting to represent an uncertain world mathematically is very 
difficult; therefore, a typical solution is to place a human “in the loop” to provide the nec¬ 
essary expertise and to guide the robot through these uncertain situations. It is apparent that 
truly autonomous solutions to this class of problems will require a different approach. This 
requirement has given rise to the development of software architectures as a means of ex¬ 
tending the domain of robotics research into applications involving uncertain, dynamic en¬ 
vironments [Ref. 6]. 

Designing a software architecture for the control of an autonomous vehicle can pro¬ 
vide a framework upon which a complete software control system can be built. Despite the 
relaxing of the requirement to represent the uncertain environment mathematically, the 
software architecture must still deal with the daunting problem of how best to represent and 
respond to the world. Another related issue is the management of the software complexity 
associated with the underlying subsystems, both software and hardware. Experience has 
shown that large software systems require the integration and coordination of the work of 
many individuals [Ref. 7]. Without extensive planning, coordination, and organization, re¬ 
sulting programs may be riddled with errors, the identification and correction of which will 
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prove costly in terms of human and monetary resources [Ref. 8]. Even then, there is no 
guarantee of perfect software. Undetected errors or interactions between individually cor¬ 
rect modules may cause unexpected behavior in the overall system. Just as problematic, the 
system may not behave as the end user expected, the result of misunderstood or incomplete 
requirements. 

B. SCOPE OF DISSERTATION 

This dissertation presents a software architecture for the control of autonomous 
vehicles operating in a dynamic environment. The problem domain addressed by this work 
has three major aspects: the control of autonomous vehicles in unstructured environments, 
the reconfiguration of the missions anticipated by this class of autonomous vehicles, and 
the reusability of software associated with this control. Each of these issues has, to differing 
degrees, driven researchers to provide better ways to design and develop control software 
for autonomous agents. Until now, however, no approach has successfully integrated all 
three requirements into a single architecture. The Rational Behavior Model (RBM), 
through the use of appropriate abstractions and the selection of different programming 
paradigms according to their particular applicability to the problem, has been defined 
specifically with these problems in mind. 

Management of software complexity is the primary purpose of any software architec¬ 
ture. The architecture must define operational and logical domains into which are placed 
the software systems that accomplish the tasks at hand. Automated reasoning is an essential 
component of the architecture if the vehicle is to effectively execute a mission while con¬ 
tending with the uncertainty of dynamically changing environments. Other issues, includ¬ 
ing mission replanning, fault identification and isolation, intervention, and the reaction to 
unanticipated events which would, under other circumstances, be handled through human 
intervention, must be taken into account within the architecttual framework. This require¬ 
ment for organization and coordination would almost certainly overwhelm a design using 
a “traditional” approach, even one involving the functional hierarchies of structured pro- 
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gramming. Again, the RBM provides a means to overcome this problem through the appli¬ 
cation of a rich set of abstractions and multiple programming paradigms. 

C. ORGANIZATION OF DISSERTATION 

Chapter II begins with a survey of previous research work on control software for au¬ 
tonomous vehicles. Following this is a discussion of the requirements associated with au¬ 
tonomous vehicle control and the problem domain relevant to autonomous vehicle opera¬ 
tion. Next, a description of the various approaches to control software architectures current¬ 
ly in use is provided. Current, significant autonomous vehicles are then recounted along 
with a description of the associated software architecture of each. The Naval Postgraduate 
School Autonomous Underwater Vehicle and its associated simulation facilities are then 
presented. 

Various programming paradigms and languages available to the designer of a software 
architecture for control of an autonomous vehicle is the focus of Chapter HI. The strengths 
and weaknesses of each, as they relate to this problem, are examined. 

In Chapter IV, the topics of computational logic, automated reasoning, and the imple¬ 
mentation issues of each are discussed. Two specific approaches to the implementation of 
reasoning, backward and forward chaining, are described, and graphical representations of 
each introduced. 

The Rational Behavior Model, a tri-level, domain specific software architecture for the 
overall control of autonomous vehicles is formally defined in Chapter V. Related software 
control architectiures for autonomous vehicle control and the shortcomings of each are pre¬ 
sented. Next, the characteristics, requirements, and constraints associated with each level 
of RBM are described. 

Chapter VI describes the results of a simulation study of an instantiation of RBM ap¬ 
plied to a real-world scenario. Specific implementation considerations are detailed and the 
solutions to each are provided. The implementations of RBM developed for this disserta¬ 
tion are explained, followed by discussion, analysis, and evaluation of experimental results. 
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Finally, Chapter Vn summarizes the contributions of the Rational Behavior Model to 
the field of vehicle control software architectures and provides suggestions for futme re¬ 
search. Appendices at the end of the dissertation contain the source code listing for the pro¬ 
grams used in the experiments of Chapter VI. A Glossary immediately follows which con¬ 
tains definitions of the many terms and concepts used throughout this dissertation and in 
common usage in the current literature on autonomous vehicle control software architec¬ 
tures. 
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n. AUTONOMOUS VEHICLES 


This chapter is designed to provide the reader with the background necessary to fully 
understand the research that follows. To this end, it begins by providing a brief historical 
survey of the evolution of autonomous mobile robots from a control software perspective. 
Of particular interest is the evolution of the software organization and logic representation 
aspects of autonomous vehicle control. Requirements and capabilities to be expected of au¬ 
tonomous vehicles are then described. The next section of this chapter discusses various 
widely recognized approaches to control software architecture development. Although 
quite diverse in nature, it is possible to categorize these approaches based on shared char¬ 
acteristics. A brief overview of significant autonomous vehicle research is given. Finally, a 
section describing the Naval Postgraduate School (NPS) Autonomous Underwater Vehicle 
(AUV) and associated simulation facilities is presented, followed by a summary. 

Due to the relative immaturity and uncoordinated nature of the research in this field, 
little has been done to standardize terminology describing control software architectures. 
This has resulted in unnecessary confusion. Therefore, a glossary devoted to the precise 
definition of common terms and concepts encountered in this area is included at the end of 
this dissertation. Primarily compiled to support the research described herein, it is offered 
as a basis for further refinement to the control software community. 

A. INTRODUCTION 

The class of autonomous vehicles is a specialization of the larger class of mobile ro¬ 
bots, which itself is a specialization of the general class of robots. The term robot, a term 
derived from the Czech robota (“forced labor”) [Ref. 9], refers loosely to a mechanical en¬ 
tity that performs in a seemingly human way. It follows that a mobile robot, besides per¬ 
forming its robotic duties, is capable of moving from one location to another by means of 
wheels, tracks, legs, thrusters, propellers, etc. Furthermore, the emulation of human behav- 
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ior implies some degree of autonomy, the ability to perform independently of human, or su¬ 
pervisory, control. Hence, an autonomous mobile vehicle, or more simply autonomous ve¬ 
hicle, is a robot capable of motion and of responding in an intelligent way to a changing 
environment without human involvement. The distinction between an autonomous mobile 
robot and an autonomous vehicle is merely one of semantics. The term vehicle implies a 
platform capable of carrying or conveying an object. All autonomous mobile robots carry 
something, even if the “cargo” consists only of its own sensory and computational devices. 

DEFINITION: An Autonomous Vehicle is a self-contained mobile robot with the ca¬ 
pacity to sense a dynamic and unstructured environment, plan an intelligent response to that 
input, and act in a way that is compatible with the accomplishment of a mission without 
human intervention. 

All robots are controlled by the basic cycle of sense, decide, and act [Ref. 10], The 
sensing portion of the cycle occurs when readings are taken by the robot of its environment. 
Although much research is currently ongoing in the areas of computer vision, modeling, 
sensor interpretation, and sensor integration [Ref. 11], the problem of sensing is generally 
well understood. However, given the speed and resolution of current sensors, the sheer 
quantity of data can, in fact, overwhelm the robot’s decision making process. The action 
portion of the cycle, manifested in the robot’s motion, is likewise well understood [Ref. 12]. 
The decision phase is the least understood and, hence, has the widest variety of solutions 
associated with it. This diversity is what differentiates the various approaches to the control 
software of robots [Ref. 6]. 

The decision phase of the basic robot control cycle is difficult to realize because the 
encoding of basic human knowledge is hard. For this reason, a great deal of effort has been 
invested in vehicles which provide the sensing and action phases of the control cycle but 
rely on a human operator for the decision-making. This occurs when the robot is teleoper- 

ated, either through a radio or cable link^ This class of vehicles is called Remotely Oper- 


1. Obviously, this also occurs when a human driver is integrated into the overall design of the system. 
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ated Vehicles (ROV) for underwater and land operations and Remotely Piloted Vehicles 
(RPV) for airborne operations. Prominent examples of these classes are the Monterey Bay 
Aquarium Research Institute’s ROV [Ref. 13], the JASON ROV of Woods Hole Oceano¬ 
graphic Institute [Ref. 14], the Navy’s Remotely Operated Vehicle for Emplacement and 
Reconnaissance (ROVER) and Mine Neutralization System (MNS) [Ref. 15], and the 
Lockheed Aquila [Ref. 15]. It may be argued that because they rely on a human to provide 
decision making, ROVs are not robots at all but rather a sophisticated extension of the hu¬ 
man’s sense and reach. On the other hand, the introduction of the new generation of cmise 
missiles and “smart” bombs blurs boundaries between remotely operated and autonomous 
vehicles. In any case, ROVs cannot be thought of as autonomous, and information concern¬ 
ing missiles which emulate human reasoning is generally classified; therefore, neither are 
further discussed in this dissertation. 

B. THE DEVELOPMENT OF CONTROL SOFTWARE FOR AUTONOMOUS 
VEHICLES 

The investigation into machine intelligence applied to mobile devices began soon after 
World War II. However, not until the development of “Shakey” [Ref. 16] in the 1960’s was 
autonomy in a robot demonstrated. Although connected to an external computer through a 
radio link, and only able to solve simple control problems in a structured environment, 
Shakey was able to navigate, explore, and learn about its environment without human in¬ 
volvement. The software written to control Shakey was assembled into several levels using 
the principle of hierarchy, a type of software architecture described more fully later in this 
chapter. 

Another significant autonomous vehicle was the Stanford Cart, a TV-equipped mobile 
robot that also was linked to a remote computer. This system underwent further develop¬ 
ment, eventually evolving into what became known as the Camegie-Mellon University 
(CMU) Rover. During this evolution, the software underwent restructuring as well, result- 
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ing in a concept of control based on a three level hierarchy communicating via a black- 
boardr data structure.[Ref. 17] 

The control hierarchy established by Shakey and the CMU rover was probably as 
much a result of the need for distributed decision making as it was a reaction to software 
complexity. Limits on computational resources required that different functions, such as 
perception, navigation, and planning, execute cooperatively on separate processors. This 
distribution tends to support the top-down approach to many control problems, where high- 
level planning is followed by navigation and finally path execution [Ref. 18]. 

Despite the promise of early experiments, research into control of autonomous vehi¬ 
cles began to wane in the 1970’s, primarily as a result of the complexity associated with 
sensory processing. It was not until the advent of the microprocessor that interest was re¬ 
vived. This breakthrough, combined with advances in robotic and sensing technology, ush¬ 
ered in a new era in which autonomous agents were not only endowed with increasing in¬ 
telligence but could be made to operate in complex, dynamic environments. [Ref. 19] 

It had been clear for many years that legged devices demonstrated advantages in im¬ 
proved mobility, isolation, and stability over wheeled and tracked vehicles in difficult ter¬ 
rain or soil conditions [Ref. 20]. Theoretical analysis, supported by experimental evidence, 
has revealed that six-legged (hexapod) designs are superior to those with two or fotu legs, 
both in terms of adaptability and stability. As the number of legs increases, however, so do 
the attendant control and coordination problems. Work at Ohio State University, which led 
to the development of the Adaptive Suspension Vehicle (ASV), gained recognition as the 
first operative multi-legged system to fully solve this problem by means of computer, rather 
than human, control [Ref. 21]. Hence, although designed to carry a human, the ASV was 
mechanically autonomous, requiring only high-level steering and velocity commands from 
the operator. Kwak [Ref. 22] demonstrated the effectiveness of several algorithms for the 


2. A blackboard, in this context, is a globally-accessible data store where problem-solving state vari¬ 
ables are maintained. Independent software entities acting upon the blackboard produce changes to the prob¬ 
lem state, incrementally leading to a solution. 
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on-line optimization of stepping patterns, and later introduced the concept of rule-based 
control of the ASV [Ref. 23]. However, despite the successful demonstration of new con¬ 
cepts by the ASV, it proved to be too slow, too bulky, and too expensive to be useful as a 
production vehicle [Ref. 20]. 

Work on the control of legged vehicles in unstructured terrain only underscored the 
challenges faced by researchers when moving their autonomous vehicles from the static, 
benign environment of the laboratory into the hostile, dynamic world. The nature and ex¬ 
tent of a continuously changing environment and the determination of what must be sensed, 
the selection by the planning agent of an action chosen from an enormous repertoire of pos¬ 
sibilities, and the accounting of incomplete data and unforeseen circumstances had to be 
dealt with by a truly intelligent control system. Such systems must do more than mimic hu¬ 
man action. They are required to reason about their world. 

One approach to this problem, grounded in traditional artificial intelligence, is the sit¬ 
uational calculus of McCarthy [Ref. 24]. Within this system, logical terms are used to de¬ 
note situations (states), events, and fluents of the problem domain^. In this approach, pred¬ 
icates in the situational calculus are used primarily to describe the context of fluent values 
in particular states, as well as to specify state transitions associated with an event in the 
problem domain. The situation calculus also contains the usual logical connectives and 
quantifiers of first order predicate calculus. Used together, general assertions about the ef¬ 
fects of events applied in particular situations can be expressed. 

Another logical formalism developed to represent and reason about dynamic domains 
is modal logic. In avoiding the explicit use of terms representing the world state, modal log¬ 
ic ameliorates the need to specify every property of the domain left unaffected by an event 
This characteristic of situational calculus is known as the/ramc problem [Ref. 25]. Various 


3. The state of a system is a collection of attributes uniquely describing the system at a specific instance 
in time. An event is used to record and describe the behavior of a system, where a behavior is a sequence of 
world states. A fluent is a functiffli corresponding to a shared property between world states and whose value 
in a given stale is the value of that property in the state.[Ref. 24] 
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t 5 ^es of modal logic have been developed, including temporal logic [Ref. 26] and process 
logic [Ref. 27]. 

The use of situational and modal calculi for the expression of reasoning introduces 
computational difficulties, however. In response, the STRIPS representation of actions was 
proposed [Ref. 28]. In STRIPS, a given state is represented by a conjunction of logical for¬ 
mulas. Events are represented by operators, each of which is composed of a precondition, 
and add list, and a delete list. This scheme for determining the ordering of successive states 
are embodied in a STRIPS rule. 

Situational and modal calculi and STRIPS provided the foundation for what was to be¬ 
come the hierarchical approach to goal-based planning [Ref. 29]. Both are forms of logic, 
and both utilize rules to represent the inference process. The primary difference lies in the 
control of rule activation, also known as chaining. Chapter IV of this dissertation explains 
this concept further. 

Real-time constraints presented a further challenge for these traditionally-structured 
systems. The deliberation required by the planners in these systems proved to be very time- 
intensive [Ref. 29]. In a hostile, dynamic world, replanning is frequently necessary and the 
welfare of the system often depends on the vehicle’s readiness to act. Furthermore, such ac¬ 
tions are often required in immediate response to the situation, leaving no time for deliber¬ 
ation. A number of systems were subsequently developed with these issues in mind [Ref. 
30]. All were characterized by a departure from goal-based planning in favor of a high de¬ 
gree of reactivity. The extreme position was advocated by Brooks [Ref. 31], who proposed 
a bottom-up solution to the control problem involving a layering of task-achieving behav¬ 
iors without regard to an internal world model. These control architectures stressed viability 
and robustness but at a cost of general problem-solving and reasoning [Ref. 29]. Demon¬ 
stration of so-called “emergent” intelligence was provided by Brook’s own robots [Ref. 32] 
and the Robart series of sentry vehicles [Ref. 33]. This approach formed the basis for the 
subsumptionist, or behaviorist, approach to autonomous vehicle control. 
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The value of reaction was not lost on the research community, however. Systems 
which had previously relied solely on hierarchical planning strategies began utilizing reac¬ 
tive procedures [Ref. 34]. This merging of hierarchical and behaviorist concepts has result¬ 
ed in many instances of the class of hybrid control architectures. Each of these major ap¬ 
proaches—^hierarchical, behaviorist, and hybrid—are explored in more detail in this chap¬ 
ter. It is appropriate, however, to first discuss the capabilities of autonomous vehicles and 
the requirements expected of their associated control system. 

C. AUTONOMOUS VEHICLE CONTROL REQUIREMENTS 

Owing to the relative immaturity of the field and the complexity of the problem of con¬ 
trol, research into mobile robots has had to address many issues in a multitude of areas. Ro¬ 
botics, computer vision, real-world modeling, sensor interpretation and integration, actua¬ 
tor and sensor control, path planning, navigation, plan execution, and system monitoring 
comprise an incomplete but representative list. The melding of this research to a physical 
vehicle has resulted in a remarkable test bed for new concepts, approaches, and technolo¬ 
gies. The diverse disciplines involved have focused on the fundamental requirement of ail 
autonomous vehicles: that they satisfactorily perform the mission given them while coping 
with a dynamically changing and unpredictable environment without human assistance. To 
meet this requirement, individual component technologies must exhibit levels of perfor¬ 
mance far exceeding the competence displayed by robotic systems operating in toy or high¬ 
ly specialized domains [Ref. 19]. 

Generally speaking, autonomous vehicles must acquire and maintain, through various 
sensors, a sufficiently detailed model of the operational environment to provide a basis for 
intelligent planning. Due to the intrinsic limitations and specialized characteristics of each 
sensor system, multiple sensor systems must be employed. This leads to a further require¬ 
ment that the vehicle possess the capability of integrating these qualitatively diverse 
streams of data into a uniform and coherent form useful to the planning portion of the con¬ 
troller. Sensor error and noise, along with incomplete data due to insufficient sampling. 
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contribute to uncertainty. In addition, position errors are caused by vehicular motion and as 
a result of external forces. The deliberation process must be capable of accounting for these 
as well. 

Obviously, the autonomous vehicle must have a means of accepting preplanned mis¬ 
sions and precompiled maps as part of a pre-mission sequence. Relying only on information 
stored internally, the vehicle must be able to identify and classify objects observed by its 
sensors. An autonomous vehicle must also deal competently with problems of navigation 
and planning involving spatial reasoning, fault tolerance, obstacle avoidance, and replan¬ 
ning [Ref. 35]. Finally, the vehicle must provide for its own ultimate safety and, in circum¬ 
stances where its warranted, the safety of humans and equipment relying on it. 

Control software architects must wrestle with the efficient organization and integration 
of the systems designed to satisfy these many vital requirements. Initial designs approached 
this problem from one of two extremes: top-down with emphasis on deliberation, or bot- 
tom-up, where the emphasis was on sensing. Recently, researchers have seen the value of 
borrowing characteristics of both, resulting in improved performance. These approaches, 
along with a discussion of inherent strengths and weaknesses, are the subject of the next 
section. 

D. SOFTWARE ARCHITECTURES FOR AUTONOMOUS VEHICLE 
CONTROL 

Control software of autonomous vehicles is a field of study that is still in its infancy 
[Ref, 36]. As the underlying hardware and computational capabilities improve, and as cost 
and size constraints are lowered, the sophistication and complexity of the control systems 
for autonomous vehicles rises. Typically, the robotic vehicle and its associated control soft¬ 
ware have been developed in tandem. When a new autonomous vehicle is built, the control 
software system is likewise built from scratch. Design, implementation, and testing meth¬ 
odologies are, at this time, introduced in an ad hoc manner. In addition, the issue of mission 
reconfigurability is often totally ignored. These circumstances have resulted in a “low-lev- 
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el” view of software construction, accompanied by a lack of formal software engineering 
techniques. This situation has prompted research into better ways of organizing software in 
an attempt to address these difficulties. The result has been the emergence of the field of 
software architecture for the control of autonomous vehicles. 

This research has resulted in a broad spectrum of software architectures. Some of these 
approaches are of a general purpose nature [Ref. 37][Ref. 38], while others are application- 
specific [Ref. 32][Ref. 39]. Only recently have the various approaches been categorized 
into four groups [Ref. 6], based primarily on the degree of deliberation utilized during sys¬ 
tem operation. These classes are hierarchical, behavioral, hybrid, and tool-based. Each has 
distinct strengths and weaknesses. Proponents of each approach point to specific instances 
in support of their chosen architecture. Ignoring the ill-defined tool-based category for the 
moment, all remaining approaches to control software for autonomous vehicles may be 
placed along the “architectural continuum”, shown in Figure 1. At one end are the hierar¬ 
chical control software architectures. At the other extreme lies the layered, or behaviorist, 
approach to control software. Hybrid architectures, which combine characteristics of the 
two “polar” camps, reside somewhere in between. This section describes these three main 
approaches in some detail and identifies current examples of each. 


Hierarchical Hybrids Behaviorist 

Figure 1. Architectures for Intelligent Control Software 


1. Hierarchical Control Software Architecture 

Systems of this type have a hierarchical structure [Ref. 40][Ref. 41][Ref. 42]. The 
problem of complexity is solved in a traditional manner whereby the task of autonomous 
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vehicle control is partitioned into successively less complex functional levels with high- 
level planning on top and low-level servo control at the bottom. Each level is subsequently 
implemented and then brought together to form the completed system. These systems are 
designed under the assumption that mission planning and mission execution algorithms 
should be abstracted to the top levels, leaving vehicle-specific functionality in the low lev¬ 
els. In support of sensory processing, a symbolic model of the autonomous vehicle’s envi¬ 
ronment is maintained internally. This world model representation contains, at a minimum, 
the vehicle’s current state as well as the current state of the environment. Some control sys¬ 
tems, such as the NAS A/NBS Standard Reference Model for Telerobot Control System Ar¬ 
chitecture (NASREM) [Ref. 43] and the Adaptive Suspension Vehicle (ASV) [Ref. 44], 
feature the use of hypotheses in task planning [Ref. 45], A planning module can therefore 
simulate the outcome of some action before it has been executed. Thus, safety and optimi¬ 
zation of planning is supported. 

Each level in the hierarchy receives commands from the level directly above and 
sensory information from the level directly below it. This relationship can be referred to as 
a command hierarchy. Data elements at the lowest level are atomic. These atoms are 
“fused” with additional data into increasingly abstract data objects as they are passed to 
successively higher levels. 

Another characteristic of this class of architectures is the increase in the update 
frequency as one moves from the top to the bottom of the hierarchy. At higher levels, this 
frequency is low, since problems are complex and the nature of data to be processed is typ¬ 
ically symbolic. At lower levels, the problems to be solved are comparatively less complex 
and, while the amount of data available is significant, the formats used are conducive to 
rapid computation. At the lowest level, many of the primitive tasks can be partially or to¬ 
tally realized in hardware. Closely linked to this temporal hierarchy are the planning hori¬ 
zons of each level. Low update frequencies result in long planning horizons, and fast update 
frequencies require short planning horizons. The exact magnitude of these periods must of¬ 
ten depend on experimentation, designer experience, and trial-and-error. 
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The control philosophy of the class of hierarchical architectures is naturally suited 
to an implementation of deductive reasoning called backward chaining. Backward chain¬ 
ing is a search strategy used by computers to solve problems of logic [Ref. 46]. In the con¬ 
text of autonomous vehicle control, the hierarchical control architecture executes its mis¬ 
sion by determining if its ultimate goal has been satisfied. To do this, the goal must be di¬ 
vided into a sequence of simpler subgoals, each of which must be satisfied before the parent 
goal can succeed. Should a subgoal fad, an alternative reasoning path is tried. This process 
continues until either all the subgoals of the parent goal can be solved or all viable alterna¬ 
tives have been attempted without success. If these parent goals can be solved, then their 
parent goals can be solved in turn. This process continues untU the initial (root) goal is sat¬ 
isfied, signifying mission completion. Automated reasoning as it relates to autonomous ve¬ 
hicle control software is discussed in detail in Chapter IV of this dissertation. 

These systems suffer from a number of disadvantages. The rationale behind task 
decomposition is based on “best guess” rather than scientific formalisms. In practice, inter¬ 
actions between components of a control system are not identified until after prototyping 
and incremental development have occurred. In any case, a poor functional specification 
may not manifest itself until far into the development cycle. Change at this point may re¬ 
quire extensive revisions and will certainly consume scarce resources, particularly if the 
logic of control is combined with other functional aspects of the software [Ref. 47]. Also, 
all modules within the hierarchy must be realized to some extent before the robot is capable 
of even the simplest of tasks. Furthermore, the existence of multiple hierarchies (command, 
temporal), viewed by different people at different stages of the project, may generate in¬ 
compatibilities. To support the system requirement for robustness and fault tolerance, pro¬ 
grammers must attempt to anticipate all possible scenarios in which the vehicle may find 
itself. These efforts often lack methodology and cannot be guaranteed to be complete. Fi¬ 
nally, such systems are difficult to explain to the customers. Mission logic is often spread 
throughout the control hierarchy, making these systems difficult to reconfigure. 
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2. Behavior-based architectures 

In contrast to the multilevel architectures, the task of autonomous vehicle control 
in behavior-based (or layered) architectures [Ref. 31] is viewed from a perspective of action 
rather than of deliberation. The overall behavior of the robot is developed incrementally. 
First, the desired task-achieving behaviors are identified. Next, they are grouped and or¬ 
dered into levels of competence. Each level represents an informal specification of a class 
of behaviors exhibited by the robot regardless of the situation in which it finds itself. The 
classes of behavior at the lowest levels incorporate the simplest behaviors; successively 
higher levels of competence imply more complex specificity of behavior. Since it is impor¬ 
tant for the control system to be responsive to high priority goals while continuously ser¬ 
vicing necessary low-level goals, each level of competence includes as a subset all under¬ 
lying levels of competence. 

With respect to the behavior-based control of an autonomous vehicle, levels of 
competence correspond to layers of the control system executing in parallel. New layers are 
added to an existing set to incrementally obtain a more competent robot. Each new layer is 
able to examine and, if required, alter data used by the next lower layer. The upper layer is 
said to subsume the lower layer, and together the layers achieve the level of competence 
associated with the top layer. [Ref. 31] 

A distinguishing feature of the behavior-based architectures is the absence of a 
central intelligent source of control and an internal representation of the external world 
[Ref. 48]. Instead, data is distributed among all levels, and each level performs its own sen¬ 
sory processing. Additionally, commands and data are not passed from level to level as in 
the hierarchical architectures. By wiring together multiple layers of control, a robot has the 
potential to exhibit an intelligent global behavior. In effect, the intelligence emerges from 
the global interaction of multiple, unintelligent agents [Ref. 32]. 

Many of the functional requirements of autonomous vehicle control are satisfied 
by the behaviorist approach. Pursuit of multiple concurrent goals may be achieved with dif¬ 
ferent layers working on different goals. The complexity and time requirements inherent 
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with data fusion are to a large extent avoided with each layer having access to pertinent sen¬ 
sors. The control system is robust in that, should the higher layers of control fail to produce 
results, lower layers continue to function in an expected manner. Finally, due to the incre¬ 
mental nature of the layering scheme, in theory at least, the subsumption architecture is 
readily extended by adding a new level of competence which provides the desired change 
in behavior. 

Reasoning in behaviorist architectures, as it relates to mission control, is data 
driven; that is, computation starts with the existing facts and derives new facts (conclu¬ 
sions) from them. These systems chain forward from conditions known to be true towards 
states which those conditions imply. The process ends when either no additional facts are 
derivable from current facts or an accepting condition (goal state) is reached. This scheme 
suits the layered control entities which rely upon sensor-based data to determine their be¬ 
havior. Data-driven reasoning and its forward chaining implementation is described in 
Chapter TV of this dissertation. 

Unfortunately, the integration strategy upon which the subsumption architecture 
is founded is validated only by a process of trial and error. Also, it is impossible to verify 
the correcmess and stability of the resulting control system. These drawbacks have serious 
implications for control of autonomous vehicles. From the user's perspective, an autono¬ 
mous vehicle must behave predictably and reliably, especially given the sensitivity and 
danger of potential missions. With pure subsumption, these assurances cannot be given at 
this time. 

Another issue not specifically addressed by Brooksian subsumption is the low- 
level control of the AV, namely the autopilot. With the laboratory robots Attila and Genghis 
[Ref. 49], both instantiations of pure subsumption control, the underlying stability of the 
system was assumed. That is, the subsuming behavior did not explicitly ensure that the ro¬ 
bot would stay upright. If the robot flipped over trying to scale an obstacle, the experiment 
was terminated. Given the nature of the missions autonomous vehicles are called upon to 
complete, and the hostile environments they operate in, it is imperative that basic vehicle 
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stability is guaranteed. Therefore, control architectures for autonomous vehicles based on 
the behaviorist philosophy generally decouple low-level control from the layered behavior¬ 
al control [Ref. 50]. The result is a two-level hierarchy, the lowest level of which is con¬ 
ventional feedback control. 

A variation of behavior-based control has been advanced by Payton, et al., and is 
described in [Ref. 51] [Ref. 52] [Ref. 53]. This architecture, while still very much behavior¬ 
ist, differs from the pure subsumption philosophy in the area of command conflict resolu¬ 
tion. In subsumption, two commands from two related behaviors that are in direct conflict 
with one another are resolved by the highest priority behavior’s commands completely 
overriding the other’s. Compromise may be appropriate; unfortunately, subsumption does 
not allow compromise. By decomposing each behavior into small decision-making units, 
more flexibility is afforded the arbiter of conflicts. Additionally, by allowing behaviors to 
express preferences for a range of commands, allowance is made for the selection of com¬ 
mands that can simultaneously satisfy multiple goals (command fusion). 

A further refinement of “pure” subsumption is presented by Mataric [Ref. 54]. 
This architecture incorporates a distributed world map representation into a homogenous 
reactive system. Although centralized world models are thought of as being incompatible 
with subsumption architectures [Ref. 48], any application requiring a solution superior to 
random walk must base its planning on a world model [Ref. 54]. The resulting control sys¬ 
tem remains fully reactive, however, due to the integration of representation with the lay¬ 
ered behaviors. This is in contrast to hybrid systems which separate the control system into 
reactive and deliberative components. 

3. Hybrid architectures 

Because these two approaches are so fundamentally different, it initially appeared 
that little commonality could be abstracted in support of unifying the field. Instead, driven 
by the realities of implementation, projects which started out from purely hierarchical or 
behaviorist control perspectives have migrated away from their dogmatic roots. In their 
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place have emerged hybrid architectures borrowing features from both [Ref. 6], Specifical¬ 
ly, the hierarchical models failed to account for the long decision cycle times required by 
their planners. In many cases, this type of computation necessitated the use of platforms too 
large to be carried by the mobile robot. The behavior-based models, on the other hand, suf¬ 
fered from their lack of explicit intelligence. Reliance on emergent global behavior did not 
instill sufficient confidence to entrust expensive vehicles to their control [Ref. 55]. 

Hence, the field has experienced a move from the extremes to the center of the 
architectural continuum. Examples of behavior-based hybrids include State Configured 
Layered Control [Ref. 56], ISE Research’s Layered Control [Ref. 50], and the Autonomous 
Land Vehicle Controller [Ref. 57]. Hierarchical-based hybrids include the Experimental 
Autonomous Vehicle (EAVE) controller [Ref. 39], the Remotely Operated Autonomous 
Robot Control System [Ref. 38], the Open Robot Controller [Ref. 58], and the Rational Be¬ 
havior Model defined in this dissertation. 

The goal of many hybrid models is to have task decomposition and explicit world 
representation at the higher levels and to employ behaviorist schemes at the lower levels. 
The middle levei(s) are given the responsibility of providing the translation and coordina¬ 
tion of commands and actions to and from the outlying levels. Hybrids have also striven to 
address the issues of mission reconfigurability [Ref. 55], implementation of automated rea¬ 
soning [Ref. 59], real-time planning [Ref. 60], and module interfacing [Ref. 61]. 

The development of hybrid approaches, like those of their predecessors, have 
lacked a formal, mathematical basis upon which to build. This is a result of the complexity 
of the software and systems involved [Ref. 62]. While isolated algorithms can be analyzed 
using traditional methods [Ref. 63], and perhaps even individual levels can be described 
formally, complete systems simply do not lend themselves to theoretical examination. In¬ 
stead, an iterative design and development approach is preferred, augmented by simulation 
studies, prior to full-scale experimentation [Ref. 64]. 
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4. Tool-based architectures 

This approach is favored by researchers that believe that no architectural principle 
can be stated at the present time. Experience alone is the driving force behind control soft¬ 
ware development in this approach. Unfortunately, in the field of autonomous mobile ro¬ 
bots, there has not been sufficient time to construct a useful pool of experience. Vehicle 
technology, software complexity, and mission formulation are current research issues pro¬ 
ceeding in parallel. Therefore, these architectures are much less applicable than those de¬ 
scribed above with respect to the current state of autonomous vehicle control software and, 
hence, wiU not be covered further. 

5. Blackboard-based Control Architectures 

Architectures employing blackboard data structures do not constitute a distinct 
group as defined by accepted taxonomies [Ref. 6]. However, many systems, both hierarchi¬ 
cal and behavior-based, employ them as a means of inter-level or inter-process communi¬ 
cations and data transfer [Ref. 17][Ref. 38][Ref. 43][Ref. 65]. Originally, blackboards were 
developed to provide communications between distinct rule bases of an expert system [Ref. 
66]. Since then, however, the term blackboard has been applied to any globally-accessible 
data structure to which multiple processes may communicate by posting messages [Ref. 
18], 

As the size of the blackboard and the number of processes using it increases, how¬ 
ever, so does the probability of undesired side effects caused by unexpected changes to 
variables. Concurrent access from independent, actively competing processes only exacer¬ 
bates the problem. To avoid this possibility and therefore improve confidence in the behav¬ 
ior of the controlled vehicle, communications between the different levels of the software 
may be constrained in various ways. This usually results in an increase in lines of code and 
a more regimented programming style. However, this price is small compared to the re¬ 
sources needed to locate the subtle bugs which can result when unrestricted interaction be¬ 
tween software modules is accomplished using global data structures. 
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E. TYPICAL AUTONOMOUS VEHICLES AND THEIR MISSIONS 


A number of significant autonomous vehicle systems have been developed in recent 
years, primarily due to advances in processor capacity and miniaturization. Several of these 
systems, along with their philosophy of software control and system integration, are de¬ 
scribed next. This list is not meant to be all inclusive, and there are certainly additional pro¬ 
grams which warrant discussion. Instead, the intent here is to highlight the current capabil¬ 
ities of these vehicles as a measure of “where the field stands” at this point in time. 

1. DARPA/UUV 

The joint DARPA/Navy Unmanned Undersea Vehicle (UUV) Program was initi¬ 
ated with the goal of demonstrating that UUVs could meet specific Navy mission require¬ 
ments [Ref. 67]. To this end, DARP A developed a test bed UUV for new and existing tech¬ 
nologies, including high energy density power sources, high data rate acoustic communi¬ 
cations, and precision UUV navigation. The missions selected for these demonstrations 
were the Tactical Acoustic System, the Mine Search System, and the Remote Surveillance 
System. 

Two UUVs were designed and built by the Charles Stark Draper Laboratory of 
Cambridge, Massachusetts. The vehicles are 36 feet in length with a 44 inch diameter hull 
and a weight, without payload, of 15,000 pounds. They are propelled by a 12 horsepower 
electric motor that can achieve a top speed of approximately 10 knots and a maximum op¬ 
erating depth of 1500 feet. A three-chaimel redundant computer system, running identical 
software, detects faults through a majority voting scheme. A full range of sensors supports 
guidance and navigation functions. Communication to the vehicle is possible over a RF link 
when surfaced and over acoustic telemetry when submerged. 

Lockheed Missiles and Space Company has been awarded the contract to provide 
mission-level control software for the DARPA UUVs with a focus on fault-tolerant behav¬ 
ior. This architecture, called Autonomous Control Logic (ACL), is purely hierarchical and 
consists of three major components: the Data Manager, the ACL Controller, and the Model- 
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Based Reasoner (MBR). The Data Manager receives, processes, and analyzes sensor and 
status data for use by the MBR and ACL Controller. The ACL Controller communicates 
commands to an underlying vehicle control systent under the direction of the MBR in sup¬ 
port of plan execution, while providing for the safety and viability of vehicle and mission. 
Finally, the MBR comprises the “assessment” functions of evaluating the impact on the ve¬ 
hicle’s capabilities due to unanticipated events and the generation of appropriate responses 
to those events. Servo and sensor control, guidance and navigation, and vehicle health and 
fault recovery are the responsibility of a related, but distinct, software system called the Ve¬ 
hicle Controller. ACL is being developed iteratively, and four prototype cycles are pro¬ 
grammed. Formal acceptance of the system is to occur toward the end of 1994.[Ref. 68] 

2. EAVE 

The Marine Systems Engineering Lab at the University of Hew Hampshire has fo¬ 
cused much of its research efforts on intelligent underwater systems. This effort is mani¬ 
fested in the Experimental Autonomous Vehicle System [Ref. 39], an AUV test bed. The 
cunent vehicle, EAVE IE, consists of two buoyancy tubes, two battery tubes, and six DC 
thrusters capable of maneuvering the vehicle in four degrees of freedom. The EAVE III ve¬ 
hicle is 51 inches long, 41 inches wide, and 51 inches deep, and its overall weight is 1000 
pounds. Its thrusters can provide a maximum speed of 1.5 knots and the vehicle has a depth 
rating of 500 feet. 

A conceptual control software architecture has been proposed for EAVE and con¬ 
sists of four levels organized into in a hierarchical fashion. These levels are labeled, from 
highest to lowest forms of abstraction, mission, environment, system, and real-time, respec¬ 
tively. The abstraction mechanism used in this architecture is based upon process execution 
time. That is, determination of the placement of software functionality is determined by 
matching the time domain of the level which best corresponds to the execution time of the 
module implementing the function. Thus, the real-time level is responsible for sensory 
management and effector control; the sensor level deals with issues of vehicle integrity and 
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provides guidance functions; the environment level builds and maintains the world model 
and performs duties pertaining to vehicle navigation; and the top mission level handles mis- 
sion-specific issues, replanning, and mission assessment. At this time, this architecture has 
yet to be fully implemented and tested either through simulation or on the HAVE vehicle. 

3. ALV 

The Autonomous Land Vehicle (ALV) was designed and developed by Martin 
Marietta Aerospace and is intended to be a test bed for research in autonomous mobility 
systems [Ref. 69]. Its dimensions are 2.7 meters wide, 4.2 meters long, and 3,1 meters high, 
providing the capacity to carry all power, sensors, and computer systems necessary to sup¬ 
port autonomous operations. The ALV weighs approximately 16,000 pounds fuUy loaded 
yet is capable of traveling both on and off road. The vehicle has an eight-wheel drive, is 
diesel powered, and driven by hydrostatic transmission. A wide range of sensors is em¬ 
ployed, including a video camera, a laser range finder, and wheel-mounted odometers. 

A control software architecture was developed for the ALV by Hughes Artificial 
Intelligence Center [Ref. 57]. This hybrid architecture is organized into four levels, each 
containing planning and perception functions. At the highest level, the mission planner is 
used to define mission goals and constraints. These are passed to the next level, which 
maintains the world model and develops plans based on maps contained therein. The result¬ 
ing route plan is then passed to the third level containing the local planner. The local plan¬ 
ning module selects and monitors reflexive behaviors at the lowest level. It is at this level 
that reflexive behaviors are used as real-time operating primitives [Ref. 51]. Reflexive be¬ 
haviors are independent of each other and execute concurrently; however, it is the respon¬ 
sibility of the local planner to partition the appropriate behaviors depending on the current 
environment. The ALV architecture has been field tested and was the first system to dem¬ 
onstrate obstacle avoidance in natural terrain [Ref. 70]. 
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4. Ambler 


The active exploration of other planets by mobile robots demands that they be ful¬ 
ly autonomous. A manned mission, even to Mars, is highly unlikely in the foreseeable fu¬ 
ture. In addition, conventional teleoperation of robots is not practical due to the long time 
delays in signal transmission due to the extreme distances involved. An alternative solution 
would involve an autonomous mobile robot capable of safely navigating extremely rugged 
terrain while intelligently gathering materials and telemetry readings and returning them to 
earth for analysis. 

Researchers at Carnegie Melon University have conducted a program to address 
the central problems of designing such a robot [Ref. 65]. The resulting prototype is called 
the Ambler, a vehicle consisting of a cylindrical body one meter in diameter and six legs 
mounted at different elevations above and around the body’s central axis. Each leg is com¬ 
posed of shoulder and elbow joints and a vertical actuator to extend or retract the foot. The 
average overall height and width of the Ambler is 3.5 and 3.0 meters, respectively. 

The proposed control architecture for the Ambler consists of a number of distrib¬ 
uted modules with a centralized controller. Planning, sensing, and actuation are handled by 
the outlying modules. Identifying and prioritizing goals is centrally managed, however. 
Modules communicate with each other by posting messages to a message-routing table 
within the central control. 

F. THE NAVAL POSTGRADUATE SCHOOL AUV 
1. Capabilities and Characteristics 

The Naval Postgraduate School Autonomous Underwater Vehicle is an un¬ 
manned, untethered, free-swimming robotic submarine. Its primary purpose is to support 
graduate student and faculty research in the areas of control technology, artificial intelli¬ 
gence, computer visualization, software architectures, and systems integration [Ref. 71]. 
The current iteration of the vehicle, shown in Figure 2, is 84 inches long and displaces 380 
pounds. A maximum speed of two knots is attained by twin counter-rotating propellers 
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driven by DC electric motors. Eight control surfaces and four cross-body thrusters provide 
a high degree of maneuverability and motion control. The battery-based power system has 
an endurance of two to three hours. A dual-processor Gespac computational platform sup¬ 
ports concurrent execution and separates high-level planning and navigation functions 
from low-level stability and actuator control functions. Miniaturized, low-power ultrasonic 
sonar, inertial navigation, and global positioning systems are also available. The small size 
and low cost of the NFS AUV are ideal for the support of research on a wide range of shal¬ 
low water missions, including search, mapping, surveillance, and intervention activities 
[Ref. 72]. 

Software control of the NFS AUV is provided by an instantiation of the Rational 
Behavior Model (RBM). RBM is defined in Chapter V of this dissertation; the NFS AUV 
instantiation and results from laboratory simulation studies are presented in Chapter VI. 

2. Simuiation Facilities 

Due to the high expenditure of resources involved in preparing the NFS AUV for 
in-water experiments, and as a means of verifying and validating software prior to integra¬ 
tion with the vehicle, extensive simulation testing is done. This process allows the system 
developers to observe the impact of a new or modified module on the total system. To this 
end, a detailed graphics simulation of the vehicle and its swimming pool environment has 
been developed. The simulation, besides rendering a visually accurate reproduction of the 
physical vehicle, includes hydrodynamic coefficients, vehicle mass characteristics, and 
variables for vehicle dynamics in depicting the AUV’s motion. By measuring the elapsed 
time between frame updates, the calculations simulate real-time motion. 

The graphical simulator acts as both the physical vehicle and its servo level con¬ 
trol system. Higher level control systems reside on separate computers and communicate 
heading, speed, depth, and mode commands to the simulation over an ethemet connection. 
For the purpose of this dissertation, the higher levels of control were hosted on Sun 
SPARCstations. 


27 


An extension of the simulation facilities for the NPS AUV is currently under de¬ 
velopment. Specifically, the integrated simulator effectively networks a three-dimensional 
graphical simulator with an exact replica of the NPS AUV computer, software development 
workstations, and assorted support resources [Ref. 73]. Once completed, this system will 
supercede the current simulator, since the lowest level control software will be that which 
actually controls the vehicle actuators and sensors. This allows for the testing of hardware 
as well as software components. The graphics workstation provides accurate representation 
of vehicle dynamics while permitting experimental evaluation of developmental software 
and post-mission reenactment from recorded telemetry. 

G. SUMMARY 

This chapter has provided an overview of the field of autonomous vehicles and their 
control. From rather humble beginnings, autonomous vehicle technology has advanced to 
the point where increasingly difficult and complex applications are deemed achievable. To 
attain the level of expectation now associated with autonomous vehicles, the requirements 
placed on the design of such a system are so numerous as to be nearly overwhelming. From 
a computer science perspective, what is most urgently needed is a comprehensive software 
architecture that provides the necessary organization and effectively manages the complex¬ 
ity of these various systems. Initially, two general approaches were taken toward the solu¬ 
tion of this problem: the deliberation-based, hierarchically-structured architecture and the 
reflexive-based, behaviorally-layered approach. Experience has shown that neither pro¬ 
vides the proper combination of intelligence, response time, and robustness required for the 
successful operation of mobile robots in uncertain, hostile environments. This has resulted 
in the emergence of a hybrid class of architectures characterized by higher-level planners 
utilizing internal world models interfacing with lower-level, reactive control systems. 

Most, if not all, software architectures for the control of autonomous vehicles reported 
in the literature remain in a conceptual state or only partially realized. Many admit to the 
uncertainty of how to proceed in the development of the “intelligent” portion of their re- 
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spective architectures [Ref. 39] [Ref. 56]. This is partially due to the emphasis of research 
placed on these projects and to the technical backgrounds of the personnel involved. Instan¬ 
tiation of software systems involves careful consideration of the computational domains in¬ 
volved. This directly influences the choice of the programming paradigms and languages 
used in the development of the system. The next chapter of this dissertation provides the 
reader with a review of the alternative paradigms, the strengths and weaknesses of each, 
and the applicability of each with respect to software architectures for the control of auton¬ 
omous vehicles. 
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in. PROGRAMMING PARADIGMS AND LANGUAGES 


A. INTRODUCTION 

Once the desired capabilities of an autonomous vehicle have been identified, efforts 
must be turned to the design and, ultimately, the implementation of the system. With re¬ 
spect to software, these phases in the development cycle can proceed smoothly for systems 
of small complexity and size. Generally, applications consisting solely or primarily of nu¬ 
merical computation are ideally suited for an imperative programming approach using a 
commonly available imperative language. Engineers, mathematicians, and scientists deal 
with problems of this type and are, therefore, most comfortable with this paradigm. How¬ 
ever, intelligent control of autonomous vehicles introduces a wider range of problems to be 
solved. Some, like navigation and servo control, lend themselves well to imperative solu¬ 
tions. Automatic reasoning, on the other hand, involves the encoding of human knowledge. 
This information is decidedly non-numeric; therefore, a different programming paradigm 
is called for, one better suited to the representation and manipulation of symbolic struc¬ 
tures. 

Software organization and data management are also considerations that must be part 
of the overall design process. The method by which modules communicate, how data is 
passed and stored, constraints on time and space, concurrency, and distributed processing 
are all issues which should influence the choice of programming language(s) used in an im¬ 
plementation. Additionally, practical issues, such as the availability of resources and the 
experience of personnel, will certainly come into play. 

Theoretically, the expressive power of most computer languages are the same. Any 
problem that can be expressed in one can be expressed in another [Ref. 74]. From a practi¬ 
cal standpoint, however, languages differ dramatically with respect to the class of problems 
for which they were designed. Each has a domain of problems in which it excels while, in 
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other contexts, the same language may prove to be unacceptably inefficient or unwieldy. 
For this reason, there is probably no “best” single language for applications involving a mix 
of problem domains. The following discussion is meant to aid the designer of autonomous 
vehicle systems in the informed selection from the wide range of candidate languages. 

B. IMPERATIVE PROGRAMMING 

The class of imperative languages have their origins in the earliest computing ma¬ 
chines. These computers had little storage and were very slow. Programmers were required 
to focus much of their energies on code optimization. Since memory typically was provided 
in the form of a rotating drum, this process entailed the calculation of instmction location 
based on the distance traveled by the drum during the execution of the previous instruction. 
Also, there existed no facilities for indexing or address modification, important features of 
the von Neumann architecture upon which most modem computers are built [Ref. 75]. 

The complexity of programming these machines led to the development of flow dia¬ 
grams and later to the now weU-established/?£)w chart. These design tools assisted the pro¬ 
grammer by describing explicitly the flow of control through the program; that is, the points 
where branching, looping, and sequencing occurred were represented by appropriate sym¬ 
bols. Program development was made even simpler as a result of the introduction of low- 
level language interpreters. By writing programs in a form other than machine code, the 
programmer could concentrate on the application at hand and leave the more tedious and 
error-prone activities to the interpreter. [Ref. 74] 

A drawback of the new interpreters was that they ran slowly. Each instmction was 
translated into an intermediate form which could then be executed by the computer. How¬ 
ever, decoding each instmction added a great deal of overhead to program execution. With 
the introduction of floating-point hardware by IBM in 1953, the overhead required by the 
interpreter began to dominate the total execution time of the program. For this reason, in¬ 
terpreters fell from favor and were steadily replaced by compilers. The process of compi¬ 
lation involves selecting pre-written and tested subroutines from libraries and assembling 
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them under the direction of the user’s code into an executable program. Translation and de¬ 
coding was performed only once, at compilation time, resulting in programs that executed 
much more quickly than interpreted programs. 

At this time, John Backus of IBM recognized that it was becoming more expensive to 
design and debug programs than it was to run them. He concluded that programming costs 
could be decreased only through the use of a system that could recognize conventional 
mathematical notation and generate code equivalent in efficiency to that produced by a 
good programmer. This effort led to the development of the Formula Translating System, 
FORTRAN [Ref. 76]. 

The original FORTRAN, like its various dialects developed through the years, was 
characterized by the distinction made within its programs of a declarative part, describing 
data areas and their initial values, and an imperative part, containing the commands to be 
executed during the running of the program. Declaratives state facts about the program 
which are used at compile-time. Imperatives, on the other hand, describe actions which the 
program obeys at run-time, such as algebraic computation, assignment, comparison, and 
branching. This distinction is characteristic of the class of imperative programming lan¬ 
guages, a class that includes, besides FORTRAN, FLA, BASIC, Pascal, C, and Ada. 

Development of these other languages was driven by three primary factors. First, 
FORTRAN’S lack of character manipulation facilities limited its effectiveness in applica¬ 
tions that were not strictly numeric. Second, FORTRAN was, for the most part, based on 
the hardware architecture of a particular family of machines and, therefore, lacked syntactic 
regularity and consistency. Third, FORTRAN programs relied heavily on the GOTO state¬ 
ment as a control-flow mechanism. As FORTRAN programs increased in size and com¬ 
plexity, they often suffered from “spaghetti-like” structuring that was difficult to under¬ 
stand, debug, and maintain. This phenomenon caused a reaction within the field of comput¬ 
er science that resulted in the introduction of structured programming, a body of 
programming methods intended to foster easier and more reliable programming [Ref. 77]. 


32 





C. FUNCTIONAL PROGRAMMING 


Imperative programming depends heavily on the assignment statement and a change- 
able memory for program accomplishment. Most imperative languages can be viewed as 
consisting of a variety of mechanisms for routing control from one assignment to another. 
In applicative programming languages, however, it is the applying of functions that is cen¬ 
tral. Hence, these languages are also referred to as functional languages. The functional ap¬ 
proach is characterized by its lack of a destructive assignment. In other words, a pure func¬ 
tion does not produce side effects; rather, it returns a value based solely on the values of its 
input parameters. Repeated calls to a pure function with the same arguments wiU always 
produce the same results. This phenomenon is called referential transparency [Ref. 78]. 

Functional programming is also characterized by its lack of control structures. By the 
judicious construction and application of functions, a GOTO statement is not required. This 
is made possible because arguments to functions may themselves be functions. For exam¬ 
ple, the IF-THEN-ELSE conditional control structure available in conventional languages 
is written functionally as the application of a “condition” function {cond in LISP) to a num¬ 
ber of parameters representing the various alternative branches. Even function definition is 
accomplished by invoking a function {defun in LISP) with arguments representing the 

name of the function, a formal argument list, and the function’s body^. One advantage of 
programming this way is its simplicity in that all components of the program are represent¬ 
ed and evaluated in the same manner [Ref. 79]. 

LISP grew out of the need within the field of artificial intelligence to represent com¬ 
plex interrelationships among primarily s 3 mbolic data [Ref. 80]. This computation is ac¬ 
complished by allowing the manipulation of lists in ways comparable to the ways impera¬ 
tive languages manipulate numbers. Lists can be compared, passed as parameters, con¬ 
structed, and taken apart. In fact, LISP data, functions, and, by extension, its programs are 
all written as lists (known as symbolic expressions or S-expressions). 


1. To be precise, this involves binding the function name to a value; hence, d^m is not a pure function. 
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Viewed as an applicative language, there are only two control structures in LISP: the 
aforementioned conditional expression and recursion. The conditional is used to define log¬ 
ical connectives such as AND and OR. As a result, the operands of a logical relation are 
evaluated sequentially as they are encountered, from left to right. As soon as one of its ar¬ 
guments evaluates to FALSE, the and function immediately returns FALSE. Similarly, the 
or function sequentially evaluates its arguments until a TRUE is returned. Remaining ar¬ 
guments are ignored. This interpretation of the logical coimectives is known as lazy evalu¬ 
ation and is opposed to the strict evaluation of Pascal which first evaluates aU logical sub¬ 
expressions before evaluating the fuU expression. Strict evaluation can lead to errors if one 
of the sub-expressions is undefined [Ref. 81]. 

The other control stmcture provided by purely functional LISP is recursion. All forms 
of iteration including the imperative WHILE, REPEAT-UNTIL, and FOR loop control 
mechanisms are performed using recursion. This is possible because recursion relies on re¬ 
ducing the unsolved cases of a problem to a form for which an answer exists. Usually this 
involves a function calling itself with successively shorter lists as parameters. Recursion 
can also be used to “map” or apply a function to every element of a list and to filter, or ex¬ 
tract, certain elements from a list. This is accomplished without the need for indices, control 
variables, or explicit bound declaration. So as to not violate the functional tenet of side ef¬ 
fect avoidance, these functions manipulate copies of their inputs rather than the inputs 
themselves. 

There are other practical benefits of functional programming. Data structures, in the 
form of lists, are treated as units, thus isolating the programmer from the mundane and er¬ 
ror-prone details of explicitly manipulating these structures and managing their storage. In¬ 
stead, these responsibilities are left to the interpreter and host machine. LISP thus supports 
programming at a higher level of abstraction than does the imperative approach [Ref. 74]. 
Another advantage of LISP is that it can be interpreted. Interactive programming at a ter¬ 
minal wdth rapid response is invaluable in the step-wise development of software. Debug¬ 
ging and program modification are not only possible “on the fly” but are greatly simplified 
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compared to the effort and resources t)rpicaliy required by compiled languages. Since LISP 
programs are themselves lists, it is convenient to manipulate LISP programs using other 
LISP programs. As a result, a broad spectrum of software tools have been written in LISP, 
including program translators, compilers, interpreters, and text editors. 

Although LISP is the closest thing to an applicative language available for general use, 
it is not purely functional because it allows for the definition and manipulation of data. 
Functions that alter the state of the computer while computing a result are called pseudo¬ 
functions or procedures. Many of these “destructive” functions evolved from attempts to 
increase the performance of LISP. Although these functions remain part of the language 
definition, the current state of computer performance has made performance considerations 
moot. Therefore, the use of destructive functions is discouraged so as to avoid undesirable 
side effects that may result. 

In addition to providing structured programming control forms, LISP has adopted the 
features of object-oriented programming as a result of the ANSI standardization of Com¬ 
mon Lisp. The Common Lisp Object System (CLOS) provides to the software system de¬ 
signer the benefits of objects and classes (which are described in detail in section E of this 
chapter) while retaining the procedural abstraction and encapsulation of “traditional” LISP 
[Ref. 82]. 

D. LOGIC PROGRAMMING 

One advantage of LISP is that it hides much of the lower-level manipulation and man¬ 
agement of data from the user. This is important because the less detail the programmer is 
faced with the less chance there is for error. Another way of saying this is that a language 
that handles concepts at a higher level than another is also “less procedural”. The user of a 
high level language can devote more effort to what is to be done and less on how to accom¬ 
plish it. In the extreme, a non-procedural language would represent only the desired goal of 
the computation; the computer would then be left to determine how the goal was to be 
achieved [Ref. 74]. 
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In many respects, this approach to problem solving is similar to automated problem 
solving in the field of artificial intelligence. Theorems involve the statement of a hypothesis 
followed by a proof linking what is known to be true to what is to be proved. The proof 
relies on the axioms and tenets of formal logic and the formulation of exact deductive rea¬ 
soning about them [Ref. 83]. Logic programming makes use of the observation that apply¬ 
ing standard deduction methods often has the same effects as executing a program [Ref. 
84]. Thus, programs express propositions that assert the existence of the desired conclu¬ 
sion. It is the job of the theorem prover to construct from the set of premises this result and, 
hence, prove its existence. 

The programming language Prolog (Programming in Logic) attempts to automate this 
process. Prolog programs consist of clauses, of which there are three types: facts, rules, and 
queries. Rules define the problem domain and facts make assertions about the domain that 
are known, or assumed, to be true. The rules and facts comprise a Prolog database. A query 
is a statement used to extract information from the program. Taken together, the three parts 
of a logic program resemble the statement of a mathematical theorem. 

The general form of a clause is <head> <body>. If the head is omitted, the clause is 
a query; if the body is omitted, the clause is a fact. A clause with both head and body is a 
rule. The head and body are composed of relationships, each of which is either an applica¬ 
tion of a predicate to one or more terms, or an atom. Prolog allows at most one relationship 
in the head, a form referred to as a Horn clause. An explanation of why this is so is deferred 
to Chapter IV of this dissertation. 

In pure logic programming, because control and logic are separated, the ordering of 
the clauses is irrelevant to the execution and results of the inference process. The program’s 
logic is based solely on logical relationships between clauses instead of their physical rela¬ 
tionship. Prolog, in the interest of efficiency and determinism, includes control mecha¬ 
nisms that greatly influence how programs are written and organized. First, Prolog uses 
backtracking as a way to explore alternative paths to a goal. If a dead end is encountered, 
the search simply continues from the last decision point. Second, by its definition Prolog 
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uses a depth-first strategy when searching through a database. It becomes the responsibility 
of the programmer to arrange the clauses and subgoals of the program so as to avoid the 
pitfalls of depth-first search. Third, as a consequence of these two characteristics, Prolog 
includes the cut (!) mechanism designed to preempt backtracking and halt the search for 
additional solutions. 

Determining if the query is a logical consequence of the program (that is, it can be 
“proved” by the rules and facts available) is the responsibility of the Prolog inference en¬ 
gine. This is itself a program, separate from the user’s program, that performs the task of 
deriving inferences from the given set of clauses. If the response to a query is yes (or 
TRUE), the goal is provable from the available assertions. If, however, the system returns 
no (or FALSE), the query has not been proven false; rather, it could not be deduced from 
the existing premises. This inference based on lack of knowledge is otherwise known as the 
closed-world assumption. It is possible to ask existential queries in an attempt to find spe¬ 
cific solutions. These queries involve one or more variables which are bound, through a 
process called unification, to appropriate values. The system will continue to search the set 
of clauses, if commanded, until all possible solutions are generated. 

Prolog has very few built-in data types and essentially no data structure constructors. 
Instead, data structures are defined implicitly by the clauses in the program and manipulat¬ 
ed by matching the data against existing expressions. As in functional programming, recur¬ 
sion is used in place of the procedural control structures of imperative languages. Unfortu¬ 
nately, attempting to apply Prolog in a purely logical way, say for integer arithmetic, is in¬ 
tolerably inefficient, particularly since the computer can implement this directly [Ref. 74]. 
By including “procedural” predicates and functions to improve performance, however, log¬ 
ical properties are compromised [Ref. 85]. 

E. OBJECT-ORIENTED PROGRAMMING 

Partly as a reaction to the “software crisis” of the 1970s, when the costs of producing 
software were increasing apparently without bound, languages characterized by their em- 
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phasis on data abstraction were developed^. Specifically, these languages, of which Ada is 

a significant example , provided an encapsulation facility supporting the separation of 
specification and implementation, information hiding, and strictly controlled access to 
function and data declarations. In addition, the concept of the class (generic type in Ada) 
was included in these languages, from which multiple instances of a data structure could be 
created. The purpose of this feature was to support software reuse, which in turn can be ex¬ 
pected to enhance program efficiency, readability, and maintainability while reducing as¬ 
sociated cost. 

These same motivations lie behind the development of object-oriented programming 
languages. These languages allow the definition of classes from which abstract data struc¬ 
tures called objects may be instantiated. Objects t 3 fpically contain a set of variables that 
may be manipulated only by specified operators defined for that purpose. These operators 
are called methods and are invoked upon receipt of a message. By restricting access to the 
methods and variables of an object, the object’s internal structure is said to be encapsulated, 
and any modifications made to this structure will not affect programs using that object [Ref. 
86 ]. 

One of the features that distinguishes object-oriented programming languages is the 
code-sharing mechanism called inheritance [Ref. 86]. With inheritance, a new class can be 
designed from an existing one by specifying only those variables and methods that differ¬ 
entiate the two. The newer subclass is said to inherit all the features of the parent superclass. 
Of course, this includes those items the parent class may have inherited from its superclass. 
The subclass relationship between classes defines a class hierarchy with inheritance oper¬ 
ating over “a-kind-of ’ or “is-a” links joining subclasses and superclasses. 


2. Data abstraction manifests itself in the Abstract Data Type (ADT), a set of data values and operations 
on those values. The representation of the data is hidden within the module. Access and manipulation of the 
data is accomplished only through the procedures provided by the module to the user. 

3. As will be emphasized shortly, Ada is object-based rather than object-oriented due to its lack of pro¬ 
vision for class inheritance. However, Ada’s support of ADTs and encapsulation is still pertinent to this dis¬ 
cussion. 


38 





Objects may contain variables that represent other objects. In this case, the containing 
object is a composite object. The variable object may be implemented in one of two ways: 
as a dependent object or as a subobject. A dependent object cannot be created unless the 
composite object is first created. Similarly, the dependent objects are destroyed when the 
composite object is destroyed. These objects share a “part-of ’ or “has-a” relationship. Su¬ 
bobjects, on the other hand, are created independently of the composite and are subsequent¬ 
ly linked through a pointer stored in the corresponding variable. Subobjects are not auto¬ 
matically destroyed upon termination of its composite object. In addition, subobjects may 
be shared between any number of composite objects [Ref. 87]. Such objects exhibit a uses 
relationship [Ref. 88]. The relationship between composite, dependent, and subobjects 
forms the basis for object (or composition) hierarchies. 

Based on the definition for object-oriented programming proposed by Wegner, a lan¬ 
guage is object-oriented if it supports objects, classes, and inheritance [Ref. 89]. Languages 
which feature the first two characteristics but lack inheritance are called object-based. Ada, 
because it has no provision for inheritance, falls into this category. 

Object-oriented features, when added to an existing language, results in a bolted-on 
language; languages designed with object-oriented principles in mind are called built-in 
[Ref. 87]. Examples of bolted-on languages are C-I-+ [Ref. 90], CLOS [Ref. 91], and Clas¬ 
sic-Ada [Ref. 92]. Built-in languages include Smalltalk-80 [Ref. 93] and EDFEEL [Ref. 94]. 

Part of the confusion associated with the object-oriented programming paradigm re¬ 
sults from a lack of generally accepted terminology [Ref. 95]. The most significant differ¬ 
ences lie in how certain mechanisms are implemented within the language, such as the as¬ 
signment and persistence of class variables and the realization of multiple inheritance. As 
the field matures, a more precisely defined object-oriented paradigm should evolve, recon¬ 
ciling current language differences to a greater degree than at present. 


39 






F. CONCURRENCY AND REAL-TIME ISSUES 


For the most part, the problem domains for which the above classes of programming 
languages were developed excluded applications where multiple processors were available 
or where execution times were constrained by fixed deadlines. With the advent of fourth 

generation programming languages^, language features taking advantage of potential par¬ 
allelism have been included. The ability to specify concurrent tasks alone is not sufficient, 
however, to meet the requirements of real-time systems. Additional considerations must be 
accounted for by those who design and implement such systems. The purpose of this sec¬ 
tion is to delineate these issues and discuss various approaches to the solution of each. 

I. Concurrent Programming 

Although research into concurrency is ongoing for all classes of languages, those 
discussed thus far are usually executed on a single processor. That is, programs written in 
these languages typically have a single active thread of control, in which one program seg¬ 
ment is executed at a time. In many cases, the performance of these programs could be im¬ 
proved if independent computations, also known as processes, were run in parallel. The 
identification of notations and techniques for expressing potential parallelism and for the 
solving of the resulting synchronization and communication problems is called concurrent 
programming [Ref. 96]. 

In general, concurrency within a program can be achieved either by specifying a 
standard interface to a multitasking operating system or by expressing it in the language it¬ 
self. Operating systems like UNIX support many executing processes in concurrent fashion 
by allocating to each use of the processor in rapid succession. The effect of this “time slic¬ 
ing” is to emulate true parallelism. 

The focus of this discussion is on the second implementation. Whereas earlier 
generation programming languages like FORTRAN and C are purely sequential, and appli- 

4. The reference here is made to fourth-generation programming languages as defined by MacLennan 
in [Ref. 74]. This category includes those languages which provide the data abstraction facility of encapsula¬ 
tion and control constructs supporting concurrency. 
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cative languages like LISP contain no provision for explicitly directed conciurency, the so- 
called fourth generation programming languages, including Ada, include distinctive con¬ 
trol structures for the expression of parallelism within their definition [Ref. 74]. Ada, for 
example, identifies separate threads of control as tasks within the main program. Signifi¬ 
cantly, concurrent programming languages provide abstraction mechanisms to isolate the 
programmer from the details of how the parallelism is actually implemented. Thus, an Ada 
program requires no modification should the underlying computer change from a single to 
a multiple processor architecture [Ref. 96]. If a single processor is available, task execution 
will be interleaved. If, however, a processor is available for each task, they will execute in 
parallel; that is, the concurrent tasks will be simultaneously active. 

Concurrent tasks must communicate with each other in order to synchronize their 
activities or exchange data. One way to accomplish this is to employ a shared (global) area 
of memory accessible by the relevant tasks. In a distributed system, however, a centrally 
accessible memory may not exist. In this case, processes must communicate through mes¬ 
sage passing. Using Ada again as an example, a task wishing to communicate with another 
invokes an entry call recognized by the target task. Synchronization is accomplished via the 
Ada accept statement Once the called task acknowledges receipt of the message, the two 
tasks proceed to execute concurrently. Note that this is unlike a procedure call, where the 
calling program is suspended until the called program completes its processing, returns the 
results, and is deactivated. Should a task reach an accept statement before the correspond¬ 
ing message is sent, the task suspends itself until the message arrives. Likewise, if a task 
attempts to transmit a message before the receiver is ready, it will be suspended. In Ada, 
this coordination mechanism is called a rendezvous. Ada also provides for the conditional 
acceptance of alternative rendezvous through the use of the select statement Other concur¬ 
rent languages, such as OCCAM, Modula, and Mesa, provide similar functionality but em¬ 
ploy widely varying mechanisms for its attainment [Ref. 97]. 

The problems associated with the sharing of data between concurrent objects is of 
significant interest within the object-oriented programming conununity. Class variables are 
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typically shared between all instances of the class, and few object-oriented languages pro¬ 
vide for the mutual exclusion of concurrent objects vying for access to these variables. At 
the individual object level, instance variables may also experience mutual exclusion prob¬ 
lems if concurrently executing methods accessing the same variables are present. Addition¬ 
ally, the consistency of class variables may be violated if a class definition is replicated on 
multiple nodes of a distributed system. Modification of one such variable at one site re¬ 
quires that every copy be similarly modified.[Ref. 98] 

When writing a concurrent program using a concurrent programming language, it 
is the responsibility of the programmer to identify the activities which may done in parallel. 
This is difficult for several reasons. Most “tried and true” design and program methods 
available were created for sequential programs. Parallel systems must be approached from 
a totally different perspective. Partitioning problems into independent threads of control is 
a skill developed through experience. Insuring the correctness of concurrent programs is 
also more difficult than for sequential programs. A mature body of proof theory has been 
built around traditional algorithms [Ref. 63], and the field of software testing has developed 
a wide assortment of methodologies whose purpose is to instill confidence in systems im¬ 
plementing these algorithms [Ref. 99]. For the most part, however, these techniques do not 
apply to concurrent programs because simultaneously executing processes can interfere 
with each other in subtle and apparently random ways. These problems occur when re¬ 
sources are shared and fall into one of two general areas: mutual exclusion and deadlock 
[Ref. 100]. Although the issues of program correctness for both sequential and concurrent 
programs are important and relate to the work presented in this dissertation, they are be¬ 
yond its scope. Additional information may be found in [Ref. 101] and [Ref. 102]. 

2. Real-Time Support 

Improved performance is the prime motivation for concurrent programming [Ref. 
103]. Certain systems, particularly those providing critical monitoring and control func¬ 
tions for a larger system, require the level of performance only true parallelism can yield. 
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In addition to managing concurrent threads of control, some systems must insure that each 
task meets specified deadlines [Ref. 104]. These systems are known as embedded or real¬ 
time systems, because they must respond to real-world requests in a timely fashion. Real¬ 
time, as implied in this context, simply refers to the timing constraints imposed on the sys¬ 
tem by the application. 

Real-time systems are categorized as either hard or soft. In a hard real-time sys¬ 
tem, the output of the system must not only be computationally correct but temporally cur¬ 
rent [Ref. 105]. Systems which operate under time-based constraints but for which a late 
result is acceptable are called soft real-time systems. Given that their safety depends on 
timely responses to dynamically changing circumstances, the lower, vehicle-control level 
of the software architecture of autonomous vehicles typically faUs into the hard real-time 
category. 

A common trait of real-time control is the substantial amount of data that must be 
sampled and processed for use by the embedded system. As a result, the language chosen 
to implement real-time control must have the ability to manipulate floating point numbers 
quickly and with a high degree of precision [Ref. 106]. System response time is dictated by 
the timing constraints placed on the controller as well as the overall efficiency required of 
the system. Three approaches are taken to meet the required level of performance: increas¬ 
ing processor speed and memory, optimizing code, and concurrent computation using mul¬ 
tiprocessors. In the future, gains of the magnitude required by ever more complex systems 
will be realized only through concurrent processing [Ref. 107]. 

Because of their numeric orientation and the availability of optimizing compilers, 
general purpose imperative programming languages are often used to in real-time applica¬ 
tions. This is something of a contradiction, as these languages do not permit explicit expres¬ 
sion of timing requirements. Nevertheless, performance specifications can often be met 
through a combination of code “tuning”, load balancing, memory management, and sched¬ 
uling policy [Ref. 108]. The major disadvantage to this approach is that it results in a rigid 
and delicate system not amenable to modification. 
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Due to the sheer complexity of real-time systems and the consequences of system 
failure, this process must be replaced with design methods encompassing system flexibili¬ 
ty, robustness, and verification. Reliance on the operating system to generate schedules that 
guarantee performance is one potential solution [Ref. 109]. From the programming per¬ 
spective, several specialized languages have been developed that provide constructs defin¬ 
ing temporal concepts such as absolute time stamping, during, period, and priority of pro¬ 
cesses. Examples include Flex [Ref. 110], ESTEREL [Ref. Ill], and Ada 9X [Ref. 112]. 
Object-oriented languages and operating systems designed specifically for use in real-time 
applications have recently appeared; an overview of these systems is found in [Ref. 113]. 
Another promising approach under investigation is the use of computer-aided software 
tools for the design and development of real-time systems [Ref. 114]. Interested readers are 
directed to [Ref. 105] and [Ref. 109] for excellent overviews of the issues involved. 

G. SUMMARY 

The system designer of a complex software architecture is faced with many program¬ 
ming paradigms and languages from which to choose. An implementation should, however, 
be driven primarily by the nature of the problem to be solved. If a varied spectrum of prob¬ 
lems exists, it may be appropriate to select a mix of languages, each suited to a particular 
application. Autonomous vehicle control serves as a prime example for this approach. 

One problem to be faced in such a project is the representation of knowledge within 
the intelligent controller. LISP was mentioned as a good language for symbolic manipula¬ 
tion. Prolog is based on predicate calculus and deduction. Although neither is ideal for the 
construction of automatic reasoners [Ref. 115], both offer viable approaches. In addition, 
another group of languages has been developed: rule-based. These topics will be covered 
extensively in the next chapter. 
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IV. LOGIC AND REASONING 


Autonomous vehicles, by definition, are designed to operate without human interven¬ 
tion, This is in contrast to Remotely Operated Vehicles which contain a “man in the loop”. 
Since a human is not available to make decisions on the spot, the autonomous vehicle must 
have the capacity to reason. Much research done in the field of Artificial Intelligence has 
striven to attribute this ability to machines [Ref. 116]. To impart knowledge to an autono¬ 
mous vehicle, facts and rules describing the problem domain in which the vehicle will op¬ 
erate must be placed into a form easily manipulated by a computer. This manipulation is 
accomplished in an orderly fashion by a reasoning mechanism using a particular control 
structure. The mechanism is an inference engine, and the control structure is the type of 
chaining employed by the inference engine. This chapter begins with a review of compu¬ 
tational logic, upon which all forms of automated reasoning are built. Next, the concepts of 
goal-directed and data-driven reasoning are discussed, as well as the implementation strat¬ 
egies of backward and forward chaining. Chaining is used by an automated reasoner called 
a rule-based system, and the next section describes them. Lastly, representations of the 
search space associated with rule-based systems, namely AND/OR goal trees and State- 
Transition Diagrams, are discussed. 

A. INTRODUCTION 

Intelligent software systems are also known as knowledge-based systems [Ref. 46] and 
are made up of two parts: (1) a knowledge base consisting of facts, rules, concepts, and the¬ 
ories, and (2) an inference mechanism, which examines (searches) the knowledge base in 
an orderly manner and answers questions, reasons, and draws conclusions. Automated rea¬ 
soning describes the behavior of such an intelligent system. If the knowledge encoded with¬ 
in the knowledge-based system represents the expertise of a human expert in a particular 
domain, the system is termed an expert system [Ref. 115]. The knowledge representation 
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used by all these systems is generally expressed in symbolic, as opposed to numeric, form. 
Various knowledge representation formalisms exist, although practical realizations typical¬ 
ly rely on some combination of predicate logic [Ref. 117], production mles [Ref. 118], and 
structured objects [Ref. 119]. Figure 3 depicts the three most common knowledge represen¬ 
tation schemes, the inference mechanism employed by each, and their relationship to expert 
systems. As can be seen in the figure, expert systems typically display characteristics of 
more than one approach. 

Rule-based expert systems that are capable of solving mission-specific problems are 
used in the construction of the Rational Behavior Model; thus, this chapter wiU focus on 
them. However, rule-based systems are founded upon the precepts of mathematical logic, 
and it is therefore necessary to introduce this topic first. 

B. COMPUTATIONAL LOGIC 

A discussion of the topic of automated reasoning must begin with an overview of the 
basics of formal logic, the science of correct thinking. What is presented here is intended 
to be an overview only, with a purpose to provide the context for what follows. For more 
thorough coverage, readers are directed to [Ref. 120]. 

Formal logic is a language consisting of expressions and a set of grammatical rules 
which, when applied, can determine the truth or falsity of expressions. Logic is formal be¬ 
cause the meaning of an expression is defined strictly by its form. In addition, logic is pre¬ 
cise about the conditions under which expressions evaluate to true or false. The body of 
study surrounding logic is often called a calculus because aU results drawn from the appli¬ 
cation of a rule depend solely on the expressions themselves and not upon extraneous ideas 
or intuition. Of interest here is the simplest logic formalism, propositional calculus, and the 
more general logic system called first order predicate calculus. 
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1. Propositional Calculus 

The propositional calculus, also known as Boolean algebra [Ref. 121], is a lan¬ 
guage consisting of a symbolic notation and rules for the manipulation of these symbols. 
Taken together, this language can perform sequences of inferences designed to support the 
validity of a theorem or hypothesis. A proposition is a symbolic representation of an ex¬ 
pression or concept that evaluates to truth or falsity. A theorem is composed of propositions 
called premises whose intended purpose is to prove another proposition called the conclu¬ 
sion. Premises are facts known (or assumed) to be true. 

Propositional calculus describes relationships between propositions using the log¬ 
ical operators AND, OR, NOT, IMPLICATION, and IF AND ONLY IF^ There are ten ba¬ 
sic inference rules in propositional calculus, one introduction rule and one elimination rule 
for each logical operator [Ref. 122]. This simple set of rules is quite powerful and is suffi¬ 
cient for a system that deals with statements consisting only of propositional constants. For 
this reason, the ability of propositional calculus to represent the real world is limited to 
knowledge of a specific nature [Ref. 115]. A logical system supporting the concepts of vari¬ 
ables (instances), predicates, functions, and quantification is needed for more general ap¬ 
plications. This more general, and hence more powerful, system is called the predicate cal¬ 
culus. 

2. Predicate Calculus 

Predicate calculus uses the concepts and rules of propositional logic while giving 
added ability to represent knowledge in finer detail. This is accomplished through the in¬ 
troduction of predicates, objects, and quantifiers. In addition, predicate logic allows vari¬ 
ables and functions of variables within a symbolic logic statement. Additional syntactic and 
semantic rules are also defined for the analysis of propositions, the interpretation of the re¬ 
sulting expressions, and the proving of valid deductions. 

1. A variety of symbols and labels are associated with each logical operator. In this work, if reference to 
these operators is required, the capitalized label is used. Associated symbols in common use are a for AND, 
V for OR, for NOT. -> for IMPLICATION, and for IF AND ONLY IF. 
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In predicate calculus, an expression is divided into two parts; the predicate and its 
arguments. Predicates represent what is known about the world and can assert some condi¬ 
tion about or relating to the arguments^. Predicates may be used to indicate an argument’s 
type or to denote a particular relationship between two or more objects. An example of a 
type predicate expression is boy(alex), indicating that Alex is an instance of the type “boy”. 
The expression is_father(ron, alex) contains a relationship predicate and represents the fact 
that Ron is Alex’s father. 

Arguments may be variables, in which case one of two special quantification op¬ 
erators are used to bind and delimit the scope of the variables. The standard quantifiers used 
in predicate calculus are the universal (V), meaning “for all”, and the existential (3), mean¬ 
ing “for some”. Rules relating to the addition and elimination of the two quantifiers, added 
to the ten inference rules of propositional calculus, constitute the complete set of rules for 
predicate logic. A thorough discussion of each rule is presented in [Ref. 122]. 

3. Reasoning 

Logic is more than simply a system for expressing facts and knowledge in sym¬ 
bolic form. Rules of inference are used to derive new knowledge from old, or to prove the 
validity of some goal. The process of drawing inferences, either in the form of new facts or 
proofs, from premises is the basis for reasoning. Before discussing the automation of this 
process, it will be beneficial to explain the two types of reasoning: deductive, where general 
premises are used to verify a specific conclusion; and inductive, where established facts are 
used to draw a general conclusion. It is more common, at least within the field of computer 
science, to use the terms goal-directed and data-driven reasoning for deduction and induc¬ 
tion, respectively [Ref. 46]. The terms forward and backward reasoning are also in general 
use; however, they are too easily confused with the rule-search control structures of for- 


2, Because predicates and their arguments are merely used as a symbolic representation of an abstract 
concept, one cannot speak of “incorrect” predicate or argument names. However, some predicate names are 
certainly more descriptive than others. The selection of these names is a matter of good programming style. 
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ward and backward chaining found in production systems. Therefore, in this dissertation, 
explicit directionality will be applied only to chaining. 

a. Data-driven Reasoning 

This type of reasoning begins with a set of premises known to be true and ap¬ 
plies the rules of logic to generate new facts. Specifically, reliance is on the inference rule 
modus ponens [Ref. 123], the elimination rule for the IMPLICATION operator. This rule 
states that given an implication and its antecedent, its consequent can be inferred; that is, if 
R —> S is given and R is known to be true, S logically follows. This new fact may in turn 
be used in subsequent inference steps to produce yet more new facts, and so on. Typically, 
this type of reasoning attempts to generate data in support of some goal or theorem [Ref. 
124]. Of course, data-driven reasoning may also be used simply to generate new knowledge 
without regard to a goal, perhaps as a method of learning. In any event, this inference mech¬ 
anism relies on the existence of facts and works toward the satisfaction of the theorem. 
Hence, this process is also known by the terms bottom-up, event-driven, and/onvarcf rea¬ 
soning. 

Data-driven reasoning must contend with two problems. The first is the po¬ 
tential for the creation of inferences having no relation to the goal. The other drawback in¬ 
volves the difficulty identifying the shortest path of inference to the goal. Often, reliance is 
placed on a heuristic to guide the selection of premises from among those available. These 
problems are exacerbated if the number of available facts becomes large. 

b. Goal-directed Reasoning 

Another approach to reasoning is to start from a goal to be proved and to rea¬ 
son backward toward the factual evidence needed to validate the goal. This approach to rea¬ 
soning is called goal-directed, also known as top-down, goal-driven, or backward reason¬ 
ing. The goal is first decomposed into simpler, constituent subgoals. Each subgoal is then 
itself decomposed. The process continues until subgoals are attained that are a direct con¬ 
sequence of the premises. This process is characteristic of a reliance on the derived infer- 
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ence rule modus tollens [Ref. 123], Modus tollens states that given the axioms R —> S and 
“iS, then ~iR logically follows. This mle is derived in that it cannot prove anything not prov¬ 
able by the ten basic rules alone; however, it can help to simplify proofs by providing “short 
cuts” to the solution. 

Most applications requiring the use of autonomous vehicles will be solved us¬ 
ing goal-directed reasoning. The “divide and conquer” approach to problem solving seems 
best suited for human understanding in this domain [Ref. 18]. In addition, the act of decom¬ 
posing the goal into simpler and simpler subgoals sheds light on which intermediate results 
must be attained and the sequence in which they must be attained. Supplied with this 
knowledge, a human user of an autonomous vehicle will possess a higher degree of confi¬ 
dence in its reasoning abilities because of this greater understanding of the problem. 

C. AUTOMATED REASONING AND RESOLUTION 

Despite the concise and unambiguous nature of predicate logic, its syntactic variety is 
not conducive to execution on a computer. As will be seen, automatic reasoners, for the 
sake of efficiency and in order to simplify the inference procedure, rely on a single rule of 
inference called the resolution principle [Ref. 125]. The specifics of resolution and its 
computer implementation are presented in this section. 

1. Resolution 

Resolution is an inference technique that solves logic problems by resolving (de¬ 
riving) new knowledge, called resolvents, from known premises. The power of resolution, 
and its importance for the automation of problem solvers, lies with the fact that it subsumes 
the fundamental inference rules of modus ponens, modus tollens, chaining, merge, and re- 
ductio. Use of this principle requires that logical expressions be placed in the Conjunctive 
Normal Form (CNF). An expression in CNF uses only the OR and NOT logical operators. 
The purpose of this transformation is to provide for maximum uniformity and standardiza¬ 
tion in the representation of premises while eliminating the need for many of the connec¬ 
tives and quantifiers used in the propositional and predicate calculi. 
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There are six basic steps to converting predicate calculus expressions to CNF 
[Ref. 126]. First, the operators IMPLIES and IF AND ONLY IF are eliminated by replacing 
them with their logical equivalent Second, the scope of negation is reduced to the atomic 
term level using DeMorgan’s laws. Third, repeated variables are standardized based on the 
scope of their quantifiers. Fourth, existential quantifiers are eliminated by introducing con¬ 
stants and Skolem functions. Fifth, intermediate forms are converted to prenex form, in 
which universal quantifiers are eliminated. Sixth, conjunctives (AND operators) are re¬ 
moved along with extraneous parentheses. The premises in the final form consist of atomic 
formulas called literals. It is upon these literals that resolution operates. 

Resolution works as follows. If x and y are two premises transformed into CNF, 
and i and j are literals of the premises x and y, respectively, and i = -ij, then a new premise 
z can be derived by forming the union of x and y minus the literals i and j. The premises x 
and y are said to “clash” on the pair of complementary literals i and j. Expressed another 
way, the clause z is the resolvent of the parent clauses x and y. When dealing with comple¬ 
mentary literals containing variables, an additional step is required prior to the application 
of resolution. During this step, the variables are matched and bound using the unification 
algorithm [Ref. 126] [Ref. 127]. 

Other representative forms, such as Clausal form and Horn clause form, are even 
more restrictive but can improve the simplicity and efficiency of automatic reasoners. 
Clausal form is similar to CNF, except that the negated literals and non-negated literals of 
each disjunction are grouped together. If the negated group are placed on the right of an 
implication arrow, and the non-negated group on the left, the negation symbols can be 
dropped. The resulting clausal form is equivalent to but easier to interpret than CNF, at least 
for humans. So, for example, the CNF statement 

—ip V r V s V -iq 

becomes, in clausal form, 

r, s p, q 

with the interpretation “r or s is true if p and q are true”. If one and only one literal is allowed 
on the left side of the arrow, the expression is said to be in Horn clause form. This is sig- 
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nificant because the syntax of Prolog rules is precisely that of Horn clauses. Hence, the 
Horn clause 


r ^p,q 

is written in Prolog as 

rp, q. 

and read “r is true if p and q are both true”. Sets of these rules can be built which, when 
operated upon by resolution, emulate reasoning. This emulation, or more precisely imple¬ 
mentation, of reasoning is known as chaining and is characteristic of rule-based systems. 
Specifics of these systems are given following a discussion of resolution and its relation¬ 
ship to the two types of reasoning. 

2. Resolution and Reasoning 

The basic resolution mechanism allows the derivation of new premises from old. 
Beginning with a set of initial premises and a theorem to be proved, resolution produces a 
resolvent from two of the original premises. This new premise may be combined with an¬ 
other premise to create another resolvent which is also added to the set. The proof succeeds 
when a resolvent matching the conclusion emerges. This pattern of reasoning moves in a 
forward direction from initial premises to concluding goal and is thus data-driven. As such, 
resolution is susceptible to the creation of inferences which have nothing to do with the 
proof at hand but whose spurious value cannot be immediately detected. In addition, there 
may be several possible paths of reasoning to the goal depending on the order in which the 
premises are combined. Circular reasoning is a trap that must be avoided as well. 

Another approach to theorem proving is to start from the conclusion to be proved 
and reason toward the evidence needed to support the theorem. This pattern of reasoning is 
referred to as goal-directed reasoning and, with respect to resolution, is equivalent to proof 
by contradiction. First, the theorem (or desired goal) is negated and added to the initial set 
of premises. Assuming the set was consistent (non-contradictory) to begin with, the new set 
is now inconsistent Resolution is then applied in the usual way. There are three possible 
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scenarios at this juncture: no premise exists containing the (non-negated) goal, in which the 
proof fails; a premise consisting only of the goal exists, in which case the proof succeeds 
because the goal and the negated goal resolve to a contradiction; or a premise containing 
the goal along with other literals is resolved with the negated goal to produce a new premise 
upon which resolution must be reapplied. In the last case, the literals of the resolvent rep¬ 
resent subgoals that need to be resolved away if the theorem is to be proven. This method 
of theorem proving is called resolution refutation. One direct benefit of this approach is that 
irrelevant inferences are avoided, since only resolvents related to the negated goal are gen¬ 
erated. 


3. Resolution Strategies 

Regardless of the type of resolution used, the drawbacks associated with both 
data-driven and goal-directed reasoning must still be addressed. The problem of combina¬ 
torial explosion of resolvents can be partly ameliorated through the choice of a resolution 
strategy. Three common strategies are breadth-first, set-of-support, and linear input [Ref. 
46]. Each strategy guides the resolution process based on some heuristic. Although each 
have distinct advantages and disadvantages, the linear input form is of particular interest in 
this discussion because it is the strategy used by Prolog. In effect, linear input requires that 
every resolvent have a parent in the base set, the original set of premises. This strategy is 

simple, efficient, and, if applied to premises in Horn clause form, complete^ [Ref. 115]. 

D. RULE-BASED SYSTEMS 

Despite the attraction of basing knowledge representation on the formalisms of prop¬ 
ositional and predicate logic, neither has provided significant insight into the machinations 
of intelligent behavior [Ref. 115]. It should be remembered, however, that these calculi 
were designed for other purposes. This shortcoming has led to the development of rule- 
based production systems for the emulation of intelligent behavior. Humans tend to asso- 

3. Completeness is the property whereby an inference mechanism is capable of generating all valid con¬ 
clusions that can be drawn ftom a set of premises. 
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ciate intelligence with regularities in behavior [Ref. 128], and the expression of these reg¬ 
ularities (at least as they are understood by the AI community) lends itself well to rules 
[Ref. 129], Thus, in expert systems, production mies generate behavior much the same way 
that functions in Lisp and relations in Prolog do. However, production systems (systems 
composed of production rules) are designed to be employed in a procedural fashion, the in¬ 
tent being to manipulate the current state of the problem towards a state closer to the solu¬ 
tion [Ref. 124]. To accomplish this, the system is said to drive production rules in a forward 
or backward direction. This process of control is called chaining. 

1. Production Rules and Systems 

Production rules were originally used in theorem provers called canonical sys¬ 
tems [Ref. 130], A canonical system contains an alphabet for making strings, some axiom¬ 
atic strings, and a set of productions. Each production is of the form 

where each a^ and bj is a fixed string; aj and a^ may be null; some or all of the aj and bj 
may be null; each Sj is a variable string which can be nuU; each Zj is replaced by a certain 
Z'j; and the arrow signifies a rewrite function. The expression ajLi.-.a^Zni is called the 
antecedent of the rule and biZ'i...bnZ'n the consequent, just as in the conditional statement 
of propositional calculus. The arrow, however, does not correspond to the logical IMPLIES 
relationship. This simple system, with the ability to scan an input string of symbols and per¬ 
form addition or deletion of symbols, is all that is required to verify proofs in a formal sys¬ 
tem. 

In expert systems, the focus is on the solving of problems. Production mles in 
these systems differ little from the rewrite rales of canonical systems, except that with ex¬ 
pert systems the key is the transformation of some initial state to one which satisfies a cri¬ 
terion representing the solution of the problem, rather than the generation and recognition 
of symbolic structures. To this end, expert systems like MYCIN [Ref. 131] and systems 
built with expert-system shell languages such as OPS 5 and CLIPS have been developed. In 
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these systems, the alphabet and string-based axioms of the canonical system are replaced 
with structures built of objects, attributes, and values. Taken together, this database of 
structures makes up the working memory of the system and generally includes the premise 
facts, goal conditions, and intermediate results that comprise the state of the problem. To 
enhance the efficiency of a production system, the working memory is normally stored in 
a high-speed memory. The time of creation or the most recent use of each data is considered 
by the system when determining the placement of data in the high-speed memory. This 
strategy is called caching [Ref. 123]. 

A rule of a production system is a two-part statement that embodies knowledge. 
Each rule consists of an antecedent-consequent (or condition-action) pair. The antecedent 
of the rule, which consists of one or more premises, is matched with the various symbol 
structures known to the system using various search and pattern-matching techniques. In 
addition, the process of matching may involve the binding of variables. If a successful 
match is made (i.e., the premise(s) of some rule are true), then the rule is said to be active. 
Subsequently, the active rule is fired, and the actions (or conclusions) specified in the con¬ 
sequent of the rule are performed. Hence, production rules have the syntax 

Pi, Pj!) Qi, Qn 

where each Pj is a premise, each Qj is an action, and if all the premises are matched to the 
contents of working memory and the rule is selected for firing, then all actions are per¬ 
formed. Another interpretation is possible, in which each Pj is a condition, each Q, is a con¬ 
clusion, and if aU conditions are satisfied, the conclusions may be drawn. In this instance, 
rules are generally expressed with the antecedents on the right hand side, the conclusions 
on the left hand side, and the arrow pointing to the left. In either case, the set of production 
rules make up the knowledge base of the rule-based system. 

A production system, besides consisting of a knowledge base and a working 
memory, must also have a mechanism for the selection of rules and the subsequent appli¬ 
cation of the rule consequent. This mechanism is known as the rule interpreter or inference 
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engine. The inference engine is itself a software system that manages the search and pat¬ 
tern-matching operations associated with the mle set. During an execution cycle, the infer¬ 
ence engine examines the working memory in an attempt to activate one or more rules in 
the knowledge base. A rule is then selected by the interpreter from the list of active rules 
and the appropriate actions carried out. Often, as a side effect of this process, the contents 
of working memory are manipulated, reflecting the new state of the problem. If more than 
one rule is placed on the activation list, the interpreter must decide which one to fire. This 
process is known as conflict resolution and is typically based on some simple heuristic. 
Such heuristics guide the interpreter and are usually based on recenmess of rule activation, 
recentness of rule firing, the specificity of the antecedents, or, more simply, priority. 

If all conflicts encountered by the system are resolved in a sequence specified by 
the designers of the system, the rule set is said to be deterministic. This characteristic of 
expert systems is very important when applied to the control of autonomous vehicles. A 
simple strategy for insuring determinism is the requirement that, for all working memory 
configurations, only one rule is ever eligible for activation. In some implementations, this 
constraint may prove to be too restrictive; therefore, the assignment of priorities to rules 
involved in potential conflicts will also ensure a deterministic ordering. 

The basic match-select-apply cycle constitutes the problem-solving process used 
by the inference engine of a rule-based system to reason and draw conclusions about a par¬ 
ticular problem. The cycle continues until either a fired rule contains an explicit command 
to halt or an empty activation list is encountered. Generally, an explicit halt command will 
arise because a goal state has been achieved, even though the goal represents an anticipated 
state of failure. An example of this would be the “trap” state entered because the power 
available to the robot is insufficient to continue the mission. 

2. Chaining 

Separate from the issue of conflict resolution is the direction in which the various 
rules are employed by the inference mechanism. This direction of rule chaining may be for- 
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ward, from conditions known to be true towards problem states established by those con¬ 
ditions; or, the direction may be backward, from some goal state towards the conditions 
supporting its establishment. This is quite sintilar to the forward and backward strategies 
found in resolution problem solving discussed earlier. Because chaining is usually con¬ 
strained to one direction, forward and backward chaining are both considered to be special 
cases of resolution [Ref. 123]. 

In a forward chaining expert system, the production rule antecedents are found on 
the left hand side of the rule. This part of the rule is also called the conditional or the IF part 
of the rule. The forward chaining inference engine attempts to activate rules by matching 
the conditionals of the rules against working memory. Once the conditional part of a rule 
has been matched, it can be fired. In some cases, more than one rule conditional is satisfied 
by the contents of working memory. These mles are activated and one is fired according to 
some selection criteria applied by the inference engine. When a rule is fired, the actions 
specified by the rule are carried out. These actions are listed in the rule’s right hand side, 
also called the consequent or the THEN part of the rule. If the executed consequent alters 
the contents of working memory, a new cycle of searching, matching, and rule firing may 
commence. 

A backward chaining inference engine starts the search for a solution with the 
conclusion (or goal). The data base is examined for the goal. If it is there, the search stops 
and the goal is proven. Otherwise, the inference engine turns its attention to the rule base. 
In the backward-chaining system, the antecedent is on the right hand side of the rule; thus, 
if the goal represented by the left hand side is to be established, the subgoals specified on 
the light hand side must first be satisfied. Subgoals of the antecedent may be related by one 
or more logical connectives. The subgoals are satisfied if they can be matched to facts in 
the database or if a rule consisting of the subgoal on the left hand side can be satisfied. The 
corresponding left side of matched rules are used as intermediate hypotheses which are 
maintained by the inference engine. Each conclusion is immediately applied against the 
rule base, thereby building a search chain. Again, search continues until the original hy- 
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pothesis is proved or until all rule-matching possibilities have been exhausted. It is possible 
that no match between an intermediate hypothesis and rule right sides is possible. In this 
case, this search path is terminated, and the search process selects an untried search path. 
An attempt is then made to match this subgoal to the right side of some different rule. If no 
further matching can be done and all possible paths have been explored for the satisfaction 
of the goal, the search fails and the inference cycle stops. 

The distinction between how forward and backward chaining differ can best be 

shown through an example"^. Given the following rule set, 

(Rl) X«>aXa 
(R2) X^hXh 
(R3) X<=>cXc 

and a start symbol p, palindromes can be either generated using forward chaining, indicated 
by the right-pointing direction of the arrow, or recognized using backward chaining, indi¬ 
cated by the left-pointing direction of the arrow. If the forward-chaining rules are applied 
in the order Rl, R2, R3 to the start symbol, the system will generate the strings apa, bapab, 
cbapabc, respectively. This is an example of forward chaining because the symbol p and 
all newly generated strings are matched against the antecedent (left-hand side) of a rule and 
a conclusion detached from the instantiated right-hand side. 

The same rule set can be used to recognize (or “prove”) palindromes. If a target 
string cbapabc is given, the sequence of backward-chaining mle applications leading to the 
construction of this palindrome can be traced. Matching the right-hand side of R3 to the tar¬ 
get string results in bapab from the instantiated left-hand side of R3. The chain continues 
by matching the right-hand sides of R2 and Rl in order, yielding the start symbol p. Be¬ 
cause this represents an acceptable condition for the existence of the original string, the pal¬ 
indrome is recognized. A target string such as abcabc will not satisfy the right-hand side of 
any rule, and therefore cannot be recognized as a palindrome within the scope of this 


4. This example is derived from one used in [Ref. 115]. 
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knowledge base. Note that this system would not be capable of recognizing the string dpd 
even though it is a palindrome. Nevertheless, production systems are usually not intended 
to be complete in every aspect of knowledge in a specific problem domain [Ref. 124]. 

In the theorem-proving literature, forward chaining is usually associated with 
“bottom-up” reasoning while backward chaining is typically associated with “top-down” 
reasoning [Ref. 46]. The type of reasoning and the direction of chaining are not the same, 
however, and the direction of reasoning does not necessarily imply the direction of the 
chaining used. The chaining implements the reasoning, and the reasoning controls the 
chaining. Newell has noted [Ref. 132] that chaining is a phenomenon of the symbol level, 
where the emphasis is on right-hand sides and left-hand sides of rules, whereas reasoning 
occurs at the knowledge level, where the distinction can be made between facts and tasks. 

Hence, the choice between a forward and backward chaining expert system for the 
high-level control of autonomous vehicles depends primarily on the shape of the search 
space of the problem. The search space results ftom the reasoning process. If the problem 
contains substantially more facts than conclusions (goals), backward chaining will produce 
the shortest path in the least time. If, on the other hand, the problem consists of a few facts 
and potentially many (or unknown) goal states, forward chaining will typically yield the 
quickest solution [Ref. 133]. 

As the number of facts and rules grows, the forward chaining system faces the in¬ 
creasingly difficult and time consuming task of determining the applicability and order of 
rule firing. Unlike backward chaiiting systems, where the goal-directed nature of the infer¬ 
ence engine guides the execution of the rules, the forward chainer must continually com¬ 
pare every fact in the current working memory with the antecedent of every rule. Before 
long, the number of comparisons required to complete this becomes unmanageable. At this 
point, a heuristic-based search algorithm is typically introduced to improve efficiency [Ref. 
124]. 

Other considerations besides efficiency may require that a forward chaining sys¬ 
tem be applied to a problem well suited for solution by backward chaining. By placing an 
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explicit ordering on the goals to be achieved by the system, it is certainly possible for a for¬ 
ward-chaining expert system to implement goal-directed reasoning. The two systems, 
working on the same problem and operating under the same conditions, will formulate the 
same results [Ref. 134]. Besides differences in efficiency, however, the systems may also 
exhibit different sequences of intermediate results. This topic is addressed in the next sec¬ 
tion of this chapter. 

E. MISSION REPRESENTATION 

The purpose of the rule-based production systems discussed above is to solve prob¬ 
lems. It is beneficial at this point to focus the problem domain and to identify a particular 
kind of production system applicable to the control of autonomous vehicles. An autono¬ 
mous vehicle must have the capacity to act intelligently. In most cases, this intelligence will 
be supplied by a human intimately familiar with the goals and subgoals required of the ve¬ 
hicle. This knowledge will be codified in the form of a rule-based expert system. Therefore, 
the purpose of the expert system is to provide the direction, experience, and insight in sup¬ 
port of mission accomplishment that would otherwise be forthcoming from a human oper¬ 
ator. The applicable problem domain, then, is the set of potential missions as defined by the 
user of a particular vehicle. 

To represent a mission is to describe, to the best ability of the mission specialist, what 
is required of the AV. Information such as the detailed specification of goals, their decom¬ 
position, the sequencing of subgoal achievement, measures of success, and alternative ac¬ 
ceptable solutions may or may not be included. In any case, it is essential for the safety and 
security of the vehicle (and of personnel and property relying on the vehicle) that this de¬ 
scription of the mission be in an unambiguous and orderly form. Rule-based systems are 
available for the implementation of such problems on a computer. However, the relation¬ 
ship between the rules is not readily evident through inspection of the rule set As an aid to 
the design, verification, and validation of these systems, graphical representations have 
been devised [Ref. 135]. Two possible approaches to representing rules and their relation- 
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ships are introduced here: the AND/OR goal tree and the State Transition Diagram (STD). 
These structures are not new and have been used to varying degrees in the fields of digital 
design, control systems, robotics, and software engineering [Ref. 121][Ref. 136][Ref. 137]. 
To meet the requirement for unambiguous execution of missions depicted by these struc¬ 
tures, additional information constraining their traversal is required. Nevertheless, both 
support the representation of a search space associated with a set of production rules, both 
explicitly account for the interconnections between the rules, and both are laid out in a style 
compatible to a particular direction of chaining. Hence, they are ideal for the purpose of 
mission representation. 

The topic of search, as it relates to rule-based systems, is discussed next, followed by 
a detailed description of the AND/OR goal tree and the State Transition Diagram. In appli¬ 
cations involving autonomous vehicle control, equivalent representations are achieved only 
if the sequence of side effects resulting from the search is the same. 

1. Search 

Given a representation of a problem in the form of a graph structure, the method 
of search must be considered. A road map is a simple example of such a graph. The goal 
of the search may be to identify the shortest route between two points assuming that travel 
must be constrained to the existing roads. Or, the search may involve the inclusion of a set 
of specified waypoints. In the domain of mission execution, the search will provide a time- 
ordered sequence of subgoals, tasks, or states which lead to the attainment of a specified 
goal state. To ensure that this sequence is the one that is expected, the search must adhere 
to a specific set of constraints. 

There are two basic categories of search; blind and heuristic. Blind search is or¬ 
derly and methodical and will eventually solve the problem if a solution exists. This sim¬ 
plest form of search utilizes a trial-and-error approach for solving a problem by examining 
all alternatives provided by the knowledge base. This process is called generate and test, 
that is, a possible solution is generated and then tested to see if it satisfies the goal condi- 
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tions. As search spaces become large, the search mechanism faces the phenomenon of com¬ 
binatorial explosion, in which new nodes are added to the search structure exponentially. 
In these circumstance, blind search may consume an unacceptable quantity of computation¬ 
al or temporal resources. For this reason, heuristics can be added to blind search to provide 
guidance beyond the exhaustive nature of that approach,[Ref. 46] 

A heuristic is formulated based on experience and empirical knowledge to guide 
the search by narrowing the search process. This is accomplished by eliminating infeasible 
or unpromising search paths from the set of potential solutions. The use of heuristics does 
not guarantee that a better solution will be found, or that a solution will be found any faster 
than that found by blind search. Often, a heuristic must be tailored to a particular problem; 
even then, it may be difficult to predict the impact on search speed and efficiency, 

T)q3ically, a heuristic involves a mathematical function that results in a numeric 
value [Ref. 133]. This value can then be compared against other heuristic values or numbers 
representing constraints on the solution. Since the operation that takes the search ftom one 
node to the next has an associated cost, the mathematical functions are also called cost func¬ 
tions. Some heuristic techniques are popular due to their general applicability. Examples 
include hill climbing, best-first, and A* search [Ref. 138], With respect to the inference cy¬ 
cle of an expert system, search techniques are employed during the pattern-matching phase, 
when rules are being identified for activation. The particular search strategy and the type 
of knowledge representation used in an expert system are not independent of each other; 
often, during the design of a system, the selection of each must be done in concert [Ref. 
115]. 

Blind search is still a viable approach, however, particularly when the problem 
has a small to medium sized search space. Moreover, as computer speed continues to in¬ 
crease, such brute-force search techniques become more viable. Two popular blind search 
methods are Breadth-First search (BFS) and Depth-First search (DFS), These differ prima¬ 
rily in the order in which the nodes of the search structure are visited. In BFS, the root node 
is searched, followed by an examination of aU the root node’s children. When this has been 


63 









completed, the nodes in the next level are searched, and so on until the goal node is reached 
or until all nodes have been searched (Figure 4a). A characteristic of BFS is that the shortest 
path between the root and the goal will always be found [Ref. 46]. Typically, the search 
proceeds downward from top-to-bottom and left-to-right. Similarly, DFS begins at the root 
and proceeds through the tree from a top-to-bottom, left-to-right fashion; however, the 
search progresses along a branch as opposed to a level of the tree (Figure 4b). If a goal state 
is not reached on the current branch, the process returns to the last node from which an un¬ 
tried path is available. As in BFS, the search continues until the goal is reached or until all 
paths are traversed. A problem with DFS is that the search may spend much effort in a deep 
subtree, far from a goal which may exist in at much higher level. An advantage of DFS is 
that it is implemented simply and efficiently. 

The search spaces associated with the fundamental, high level control of autono¬ 
mous vehicle missions are typically not large enough to benefit from heuristic search. Fur¬ 
thermore, the necessity for determinism on the part of the inference mechanism supports 
the use of a predictable, exhaustive search technique like DFS or BFS. On the other hand, 
path-planning and replanning algorithms which may involve much larger search spaces and 
less restrictive timing requirements would be good candidates for heuristic search. 

2. AND/OR Graph 

State graphs, by definition, may contain cycles. This may properly represent the 
problem at hand; however, infinite loops are not computationally feasible. For this reason, 
state graphs are often converted to a cycleless structure called a search tree. The initial state 
node is called the root of the tree; the terminal nodes are the “leaves” of the tree, those nodes 
with no children; and all remaining nodes make up the intermediate nodes (subgoals) of the 
tree. Each intermediate node has exactly one parent and at least one child. The root node 
comprises level 0 of the tree; the children of the root comprise level 1; the set of children 
of level 1 nodes make up level 2; and so on. The nodes of the tree are coimected to each 
other by arcs. 
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(a) Breadth-First Search 



(b) Depth-First Search 


Figure 4. Blind Search Strategies 
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A further refinement to the search tree is the AND/OR tree [Ref. 46] [Ref. 139]. 
In this structure, the branches from a node to its successors may be related in one of two 
ways. Branches representing alternative paths have a logical OR relationship; that is, one 
branch of several may be the path to the goal. In other circumstances, the achievement or 
traversal of multiple subgoals may be required before the goal is satisfied. These subgoals 
are related through a logical AND operator. In this case, each subgoal must be satisfied or 
the problem cannot be solved. A combination of logical AND and OR relationships may be 
represented by the AND/OR tree as shown in Figure 5. In this figure, the arcs leading to the 
subgoals related by an AND share a single point on the lower edge of the parent node. This 
grouping of arcs is referred to as a hyperarc [Ref. 137]. Single arcs leading away from a 
node identify a subgoal related to the parent’s other subgoals through an OR relationship. 
Separate hyperarcs associated with the same parent node are logical disjunctions. 

These structures are static in that they only convey the logical relationships be¬ 
tween nodes but nothing about the sequence in which the branches are searched. However, 
this information is essential to the validation of goal specification and attainment by auton¬ 
omous vehicles. In the particular case of the Rational Behavior Model, goal sequencing is 
explicit and hence must be reflected in the graphical structure. For this reason, AND/OR 
goal trees are used to express goal decomposition as well as execution sequence. Specifi¬ 
cally, a depth-first (top-down, left-to-right) traversal, as used by Prolog, is assumed, 

3. State Transition Graph 

The conventional State Transition Diagram (STD) [Ref. 136] is a modeling tool 
for describing the time-dependent behavior of a system. Each node of a state transition 
graph represents one of the possible states of the problem. A state is a set of attributes char¬ 
acterizing a system at a given time such that no knowledge of past inputs is needed to de¬ 
termine the future behavior of the system. Generally, the number of states in the system’s 
set of possible states is finite. The directed arcs in an STD represent valid state transitions 
which occur when a specific condition is detected. A condition is an event in the environ- 


66 



R ^ PQ + ST 
P<-U + V 
S<-W + XY 
T<-Z 


Figure 5. Representation of a Rule Set as an AND/OR Tree 
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ment of the system, such as an interrupt or the arrival of a data packet, that typically leads 
to one or more actions taken by the system. The arc points to the state entered after the ac¬ 
tions have been applied. In a multilevel STD, any individual state of a higher-level diagram 
can encapsulate a lower-level diagram that further describes the higher-level state. The fi¬ 
nal state(s) in the lower-level diagram then corresponds to the exit conditions in the higher- 
level state. This decomposition, which may be recursively applied, gives order and under- 
standability to an otherwise complex diagram and represents a standard approach to the de¬ 
sign and analysis of complex, state-based systems [Ref. 136]. 

The notation used for conventional STDs requires that responses, in the form of 
state transitions, be identified for all possible conditions. This may lead to states which have 
two or more successor states. To avoid nondeterminism, the conditions for each transition 
path must be exhaustive and mutually exclusive. For example, if some condition X is need¬ 
ed to trigger a transition firom state A to state B, and some other condition Y causes a tran¬ 
sition from state A to state C, then it must be true that X n Y = 0. 

A state transition diagram describing a mission based on the forward-chaining control 
approach may involve states which have multiple successor states but transition conditions 
which are not mutually exclusive. Following the example from the previous paragraph, this 
would result when, for conditions X and Y, X n Y 9^^ 0. This gives rise to a conflict, the 
resolution of which must be accomplished to ensure the proper (i.e., expected) move is 
made. Since traditional STD notation does not make allowance for this, an extension called 
the state transition diagram with path priorities is now introduced. This graphical represen¬ 
tation is similar in purpose to the Logical Path Graphs of [Ref. 135], except that nodes refer 
to individual search states, and explicit priorities are assigned to transitions which may be 
in conflict with each other. This would occur when the associated rules were activated at 
the same time [Ref. 140]. 

DEFINITION: A State Transition Diagram with Path Priorities models the time-de- 
pendent behavior of a system containing state transition conditions which may not be mu- 
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tuaily exclusive. Conflicts in determining the next state are resolved through the use of pre¬ 
assigned, numerical path priorities. 

A state transition diagram with path priorities is shown in Figure 6. This diagram 
reflects essentially the same information as a standard STD. Again, each node represents a 
valid state of the system. An edge from node i to node j indicates that, as a result of rule i 
firing, rule j will be activated. Note that such an edge does not necessarily mean that rule] 
will fire immediately after rule i, only that mle j will be added to the agenda (the list of 
active rules). Conflicting state transitions, in the form of simultaneous activations caused 
by conditions coincident with each other, are represented by multiple arrows extending 
from one state and joined by a broken arc. This indicates that one, all, or some combination 
of the transition paths may be active depending on the current conditions in which the sys¬ 
tem finds itself. The child nodes pointed to by these arrows represent the possible successor 
states, and the path selected depends on the conflict resolution strategy employed by the 
inference engine. The strategy employed is determined a priori by the designers of the ex¬ 
pert system. In the example of Figure 6, numerical priorities and alphabetic conditions are 
associated with each conflicting transition path. If a conflict should arise, as in the case 
when conditions X, Y, and Z are aU applicable, the arrow associated with the highest-pri- 
ority active transition is the path taken. The use of priorities is consistent with the depth res¬ 
olution strategy, as, for example, in the left-to-right order in which Prolog treats disjunctive 
clauses [Ref. 141]. It should be noted that the STD of Figure 6 may execute as part of a 
high-level, mission control loop. Therefore, the combination of active successor states to 
state A may change from iteration to iteration. 

Both AND/OR goal trees and State Transition Diagrams are useful for the visual¬ 
ization of the relationships between rules in a rule set. However, it should not be inferred 
that either is essential in the design or implementation of such systems. In practice, these 
structures are not commonly employed for any but the most concise problems, as they sim¬ 
ply become too unwieldy. Instead, software tools specifically designed to assist in expert 
system creation and maintenance should be utilized to manage complexity [Ref. 142]. 
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Figure 6. State Transition Diagram with Path Priorities 
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F. SUMMARY 

This chapter introduces the concepts of automated reasoning pertinent to the Rational 
Behavior Model software architecture, a concept presented in the next chapter. The solution 
of problems, in the form of mission planning and control, must be achieved by the human 
expert prior to developing the expert system capable of controlling the autonomous vehicle 
in hostile environments. Missions are developed through the application of a reasoning pro¬ 
cess. Typically, in the domain of autonomous vehicle mission control, goal-driven reason¬ 
ing is required since the explicit sequencing of subgoals and their execution is involved. 
Next is the translation of the resulting logical steps into a form that can be readily manipu¬ 
lated by a computer. Rule-based languages have been developed for this very purpose. 
Rules are created which embody the logical relationships between what is known and what 
is to be achieved. The rules are then gathered together along with certain facts to form a 
knowledge base. An inference engine, by searching the knowledge base, can then infer new 
knowledge from existing facts. If the knowledge base has been designed to emulate the rea¬ 
soning performed by the human operator of a vehicle under a variety of circumstances, the 
resulting expert system may reasonably be expected to successfully control a like vehicle 
autonomously. As will be developed further in the next chapter of this dissertation, the con¬ 
cept of using an expert system to exercise mission-level control over an unmanned vehicle 
is fundamental to the Strategic level of the Rational Behavior Model. 
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V. THE RATIONAL BEHAVIOR MODEL 


The Rational Behavior Model (RBM), a tri-level software architecture for the control 
of Autonomous Vehicles, is defined in this chapter. Each level is explained in terms of its 
functionality, abstraction mechanisms, implementation restrictions, and its interface with 
the entity to which it is joined. This discussion is preceded by an introduction to several 
related tri-level control software architectures and a discussion of fundamental concepts 
relevant to this work. 

A. INTRODUCTION 

Traditional approaches to the development of software for autonomous vehicle control 
systems have typically involved significant numbers of individuals working independently 
but communicating frequently so as to insure consistent interfaces between software com¬ 
ponents [Ref, 143] [Ref. 144]. T)q)ic3^y5 these systems are constructed from requirements 
provided by end users who have well conceived ideas for what the system is to accomplish 
and the sequence of tasks required to attain these goals. These requirements are passed to 
software systems analysts whose job it is to design and implement software that realizes the 
user’s requirements. If a physical system is involved, such as an autonomous vehicle, yet 
another group of specialists must be consulted to insure proper integration of the software 
with the hardware. Thus, construction of a software system for the overall control of an au¬ 
tonomous vehicle must involve the coordination of and the reliance upon individuals from 
varying backgrounds. In addition, software incorporating concepts at a high level of ab¬ 
straction (mission planning and control) must interface with software concerned with a 
much lower level of vehicle control (stability and hardware manipiolation). One solution is 
for the software analysts to ask these experts for their requirements which are subsequently 
translated into a form understandable by computer scientists. This is a time consuming pro¬ 
cess fraught with the potential for error, misunderstanding, and ambiguity. Faulty require- 
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merits inevitably result in the alteration of the system’s design. Any partial realization of 
the original design will, of course, be affected. 

Once a complex software system is delivered, it may be subject to requests from the 
user for additional or modified functionality. Software systems which control autonomous 
vehicles are especially susceptible to these requests, since such vehicles will be expected 
to perform a wide range of missions. New missions may imply new capabilities, affecting 
hardware, software, or both. Changes of this nature are often very difficult to realize in soft¬ 
ware because the “high-level” competency of the system is typically composed of many 
simpler capabilities inextricably intertwined throughout the system [Ref. 56][Ref. 55] [Ref. 
23], 

These two problems, the effective linking of high-level symbolic computation with 
low-level vehicle control software and the modification of same, directly relate to the ar¬ 
chitecture of the software system. For a particular problem domain, a software architecture 
founded upon levels of abstraction will allow for expression of the problem in terms recog¬ 
nizable by the experts in the given problem domain (or subdomain) [Ref. 55]. 

DEFINITION; A software architecture of a system encompasses the conceptual de¬ 
sign and organization for the software. The architecture includes, but is not limited to, a de¬ 
scription of the abstraction mechanisms, division of responsibility, and specification of ex¬ 
ternal interfaces through which the software entities communicate with each other and the 
external world. Each software entity, also called a module, is an independent conceptual 
unit within a software system. 

The software architecture is an essential component in the design of a software system 
for the control of an autonomous vehicle, because therein lies the key to software mainte¬ 
nance, reuse, and modification. Most existing software architectures omit firom their con¬ 
ceptual definition any reference to the programming paradigm best suited to implement that 
abstraction. This omission can only weaken the architecture, since selection of an inappro¬ 
priate language may introduce inefficiency and negatively affect understandability. 
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By selecting an appropriate programming paradigm, the inherent power of the lan¬ 
guage can be brought to bear on the problem. Additionally, the domain expert, given the 
proper training, may become directly involved in the implementation of the system. The 
obvious advantage to this approach is that the expert can apply knowledge directly without 
having to verbalize it to a software analyst. This is particularly useful during the acquiring 
of knowledge for the construction of an expert system at the higher symbolic level and dur¬ 
ing the integration of the lower numeric-level control software with the rest of the system. 
Of course, there must exist an intermediate level providing an interface between the two 
disparate outer levels. 

Abstraction mechanisms, in concert with the programming paradigm, can also accom¬ 
modate requests for system modification. Areas of the system effected by changes in re¬ 
quirements may be isolated within a single abstraction level. Architectures that can accom¬ 
modate change are characterized by constituent software modules which have well-de¬ 
signed external interfaces, strong cohesion, and minimal coupling [Ref. 145]. Cohesion 
defines how closely related the internal elements of a software module are to one another, 
and coupling is a measure of the strength of the interconnection among software modules. 

The RBM architecture has been conceived with these features in mind. To accomplish 
this, each level of RBM embodies a particular aspect of the overtill control problem. In ad¬ 
dition, particular programming paradigms have been selected, based upon their expressive 
power, for the realization of these levels. Although dividing control software into multiple 
levels of abstraction is not a new concept [Ref. 37] [Ref. 39], employing multiple program¬ 
ming paradigms in the implementation of those levels is much less common [Ref. 146], The 
expression of global behavior through the use of a top-level, rule-based doctrine is unique 
to RBM and its antecedents [Ref. 23]. Each level of RBM is characterized by a specific ap¬ 
proach to design and implementation which uniquely identifies this software architecture. 

The Rational Behavior Model was first introduced in [Ref. 147]. The informal concept 
of RBM has since been refined with the results presented here. Included is the addition of 
several important, defining constraints placed on the original model. These constraints are 
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deemed necessary if the desired traits of software development and flexibility described 
above are to be implemented practically. In addition, this work provides definitions for 
many terms and concepts associated with the control software of autonomous mobile sys¬ 
tems in general and RBM in particular. 

B. TRI-LEVEL CONTROL SOFTWARE ARCHITECTURES 

Multi-level organization of complex systems has been utilized for millennia in the 
form of military, government, and business bureaucracies. The success of these hierarchies 
is founded on the general decision-making that occurs at the top level and the increasing 
specialization of functionality at the bottom levels. Resources can be applied most effi¬ 
ciently when the overall problem at hand has been decomposed into a finite number of sim¬ 
pler, more easily understood, tasks. The degree to which problems are decomposed, and the 
number of levels into which the hierarchy is divided, is usually resolved by experience 
based on one or more abstraction criteria. This concept applies equally well to the software 
solution to the problem of mission and vehicle control of autonomous agents. 

As the complexity and scope of real world applications involving autonomous agents 
increases, the single-level control architectures of the past have proven to be inadequate in 
dealing with the problem of software complexity [Ref. 37]. Hence, software engineers have 
utilized mechanisms based on abstraction to deal with this problem [Ref. 145]. This has led 
naturally to multi-level software hierarchies which exhibit similarities to human bureau¬ 
cratic structures. The number of levels resulting from this process is somewhat arbitrary; 
however, a tri-level organization supports coherent abstraction while retaining simplicity 
of implementation and efficiency of communications. Some prominent examples of tri-lev¬ 
el control software architectures and the important characteristics of each are described 
next. 

1. CMU Mobile Robot 

This system, which evolved directly from the Stanford Cart, was developed 
during the time frame from 1981 to 1984 [Ref. 17]. The concept of control used for this 
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robot was based on a three-level hierarchical structure. At the top was the “Planner” level, 
followed by an intermediate “Plan Execution” level, and a lower “Actuators and Sensors” 
level. The levels communicated with each other by posting messages to a blackboard [Ref. 
66] data structure. 

2. Saridis 

An early proponent of “intelligent” control of robotic vehicles, Saridis recognized 
three basic levels of control called the organizational, coordination, and hardware control 
levels [Ref. 37]. According to Saridis, these levels fall within the research areas of artificial 
intelligence, operations research, and control theory, respectively. Further work by Saridis 
has provided a basis for the design of the middle, coordination level through the use of Petri 
Nets [Ref. 148]. However, an architectural instantiation utilizing these ideas has yet to 
appear. This work is significant due to its proposed conceptual organization of intelligent 
robotic system control software. 

3. SSS 

This architecture [Ref. 149] consists of three levels characterized by their treat¬ 
ment of time and space. SSS is an acronym for Servo, Subsumption, Symbolic, levels which 
imply a progressive quantization of first space and then time. The lower, servo level oper¬ 
ates in a domain of continuous time and continuous space; that is, the state of the world is 
being constantly monitored by the servo system, and this state is typically represented in a 
numerical format The middle subsumption level also continuously checks the state of the 
world, but generally responds only to certain specific situations. In this way, the state of the 
world is discretized into a small number of special task-dependent categories. Thus, this 
“subsumption” level is said to operate in continuous time and discrete space. The Symbolic 
level, while also operating as “situation recognizers”, reacts only on the basis of significant 
events. Thus, both space and time are discrete at this level. 

Each level of SSS is seen to operate individually, with inter-level coordination oc¬ 
curring over carefully designed interfaces. Each interface consists of a command link from 
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higher to lower and sensor link from lower to higher. Commands from the symbolic to the 
subsumption level act to parameterize certain modules. By turning behaviors on and off, 
the Symbolic level guides the system in its attainment of the goal by introducing coopera¬ 
tion amongst the possibly conflicting behaviors of the Subsumption level. The controllers 
of the Subsumption level adjust setpoints which are sent to the servo loops of the Servo lev¬ 
el over the command interface between these two levels. 

The sensory interface from Servo to Subsumption level carries unprocessed “en¬ 
vironmental” data fed to a signal-processing front-end located in the Subsumption level. 
This device consists of various matched filters designed to equate certain classes of sensory 
states since they would all call for the same motor response by the robot. Other classes re¬ 
quiring a different response by the robot are discriminated by the matched filter recogniz¬ 
ers. If a specified group of recognizers are all valid, this leads to an event detection signal 
being passed from the Subsumption to the Symbolic level for processing. 

The SSS architecture has been implemented to solve navigation problems for a 
wheeled laboratory robot, as described in [Ref. 149]. High-level, “strategic” control pro¬ 
vided by the Symbolic level is determined by referring to a geometric map of the robot’s 
world. It is unknown whether this architectiure could be adapted to handle a dynamic envi¬ 
ronment such as an autonomous vehicle might find itself. Nevertheless, the SSS architec¬ 
ture recognizes the importance not only of conceptual abstraction for the solution of the 
control problem, but also the requirement to design specialized interfaces between the lev¬ 
els. These important features are shared by the Rational Behavior Model. 

4. Open Robot Controller 

This work involves a three-level architecture for the control of robotic systems de¬ 
veloped by the Institut de Recherche en Informatique et en Automatique (INRIA) of 
France. An application is created from an existing library of robot-tasks. Each robot-task 
associates a local behavior related to events recognized by sensory signals and a control 
scheme dedicated to some physical device [Ref. 150]. An object-oriented design approach 
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is taken with respect to the robot-tasks. By doing this, coherence between the robot-tasks 
is ensured, understandability is improved, and realization of a man-machine interface is fa¬ 
cilitated. In addition, reasoning, expressible in terms of predicate logic, is available to the 
application designer through an as yet unnamed programming language [Ref. 58]. Further¬ 
more, applications expressed in this language are subsequently translated into Esterel, a 
synchronous, parallel, imperative language especially well suited for the implementation of 
reactive systems [Ref. 111]. In this context, the term “reactive” equates to “event-driven” 
whereby the behaviors are initiated through the object-oriented message-passing mecha¬ 
nism. This architecture utilizes the abstraction mechanism of class hierarchies at the task 
(middle) level. 

5. Events and Actions/ARCS 

This control software architecture [Ref. 55] has been designed specifically to sup¬ 
port the Autonomous Remotely Controlled Submersible (ARCS) built by International 
Submarine Engineering (ISE) of Canada. This system incorporates the concepts of object- 
oriented programming and techniques of event-driven, real-time software. Most important¬ 
ly, an emphasis on mission-reconfiguration improves the ease and rapid customizing of 
software for different applications. The architecture is constracted from software objects, 
or components, which respond to external inputs (events) by producing appropriate outputs 
(actions). These components are gathered and maintained in a library. Construction of a 
real-time control software system is then a matter of selecting the required components 
from the library, specifying their parameters, and defining the interconnections between 
them. In an effort to allow non-programmers to configure their own system directly, a sim¬ 
ple interface language is available. The language is declarative, meaning the statements 
may be rearranged in any order without altering the functioning of the system. Once writ¬ 
ten, the “script” file is interpreted to initialize the data structures for system execution. 
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6. State'Conflgured Layered Control 

In Chapter II of this dissertation, it was stated that a primary drawback of the 
“pure” subsumption (layered) control approach advocated by Brooks [Ref. 31] lay in the 
inability to explicitly configure the desired mission. State-Configured Layered Control 
[Ref. 56] was developed in an attempt to address this shortcoming. Tests with an autono¬ 
mous underwater survey vehicle [Ref. 151] indicated that the complexity of the layered 
control architecture increases significantly as the number of required behaviors increases. 
Furthermore, it was found that the overall vehicle performance is sensitive to subtle inter¬ 
actions between the concurrently-executing behaviors. 

To overcome these unanticipated interactions, a higher level of control was added 
to guide the behaviors. This is accomplished by partitioning, or configuring, the layered 
control structure according to the current phase of the mission in an attempt to minimize 
the number of behaviors active at a given time. Determination of the current state is pro¬ 
vided by a state transition table, which accounts for all possible states and the transitions 
between them. Each state determines which behaviors are active, establishes the parameters 
required by each, and specifies the priorities necessary for conflict resolution. 

WhUe State Configured Layered Control acknowledges the need for a higher lev¬ 
el coordinator of layered behaviors, the state transition table presents its own problems with 
respect to modification [Ref. 152]. At present, a change in mission requires a complete re¬ 
configuration of behaviors, involving the constmction and validation of a new state transi¬ 
tion table. 

This architecture has led to the forward-chaining variant of RBM, henceforth la¬ 
beled RBM-F, The state transition table can be employed as a conceptual tool for the de¬ 
velopment of the top level control software, implemented in a forward-chaining, mle-based 
language. RBM-F is examined in detail in Section D of this chapter. 
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7. NASREM 


An elaboration of Saridis’ three level model, NASREM actually encompasses a 
precisely defined six level software hierarchy for telerobotic applications [Ref. 43]. The 
NASREM architecture has since been generalized to permit application to a software sys¬ 
tem for the cooperative control of multiple AUVs [Ref. 153]. NASREM is an example of 
a purely hierarchical approach, in which behaviors contained at one level are initiated only 
when directed by the next higher level of the hierarchy. Together, these levels are said to 
form a command hierarchy. In addition, each level operates at a time scale longer than that 
of the level immediately below it in the hierarchy. The timing characteristics of each level 
thus form a temporal hierarchy. Each level consists of a set of closed-loop control systems 
containing sensory processing, world modeling, task decomposition, and performance 
evaluation unique to that level. Levels communicate with each other via global memory. 
The command and temporal hierarchies of NASREM are also to be found in RBM, al¬ 
though interlevel communication is much more restrictive in the latter. 

Even though aU interfaces are well defined, the NASREM architecture is some¬ 
what inflexible, leading researchers to implement subsets and variants of the standard. This 
situation has caused the NASREM standard itself to evolve in an effort to become more ac¬ 
ceptable to the research community. [Ref. 55] 

Figure 7 pictorially shows the relationship between several of these software 
control architectures and RBM. An architecture connected to another on the left by a solid 
line is a subclass of the more general architecture. Much significant research involving 
control software designed around levels of conceptual abstraction has evolved from 
Saridis’ original work [Ref. 37]. The subclass of architectures labeled SSS took Saridis’ 
model a step further by specifying the time and space domains in which each level operates. 
The Rational Behavior Model refines SSS by associating a particular programming 
paradigm to each of the three levels while slightly refining the time and space domains at 
each level. The two subclasses of RBM, RBM-B and RBM-F, defined later in this chapter, 
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are distinguishable by the approach taken to the implementation of their respective top 
levels. 



RBM-B 


RBM-F 


Figure 7. Tri-level Software Control Architectures 


C. FUNDAMENTAL CONCEPTS 

Before a formal discussion of any software system begins, a clear, concise definition 
should be given for all terms and concepts which might introduce confusion or ambiguity. 
Too often in the field of control software for autonomous vehicles this requirement has not 
been adequately addressed, resulting in a general lack of consistency of terminology among 
researchers. In this section, definitions for the concepts needed for the subsequent formal 
specification of RBM are given. Additional definitions will be introduced throughout the 
remainder of this dissertation as the need arises. 

Complex systems are often organized into hierarchies to enhance efficiency and to fo¬ 
cus the control of the problem-solving process. Given such an organization, complex prob¬ 
lems can be solved most efficiently by successively decomposing the problem into increas¬ 
ingly simpler subproblems. More than one level of the hierarchy may join together to ac¬ 
complish this, with the higher level forwarding its results to the lower level. At some point, 
the resulting components of the decomposition may be readily represented algorithmically. 
Such algorithms, if properly constructed, can produce clear, conect, and unambiguous in- 


81 







structions which, when carried out by the lowest levels of the hierarchy, will collectively 
result in the solution (accomplishment) of the initial problem (root goal). 

DEFINITION: A level of control is characterized by a conceptual abstraction, of 
which temporal, spatial, and command hierarchies are the most common. 

In a manner similar to that used by organizational hierarchies, a complex control prob¬ 
lem may be best solved by decomposing it into smaller, simpler parts. Initially, the parts 
into which the problem is broken are themselves abstract problems; that is, little thought is 
given to the detailed functionality characterizing these abstractions. Instead, the concern is 
to successively decompose the problem into a finite set of simple subproblems which lend 
themselves to easy implementation. Each component subproblem created in this way iden¬ 
tifies a goal to be attained on the way to solving the overall problem. 

DEFINITION: As Problem decomposition of the root goal proceeds, the intermediate 
and primitive goals may be placed in a tree structure to assist in the orderly search for a 
problem solution. 

DEFINITION: A goal tree is a graphical representation of AND/OR goal decomposi¬ 
tion, with the root node representing the root goal, the leaf nodes representing the primitive 
goals, all other nodes representing intermediate goals subject to further decomposition, and 
the connecting arcs representing the logical relationship between subgoals and the goal 
from which they were decomposed. 

After the problem has been decomposed into its constituent primitive goals, efforts can 
be directed to the satisfaction of these goals. These efforts, initiated by a primitive goal, typ¬ 
ically involve the coordination of one or more behaviors. 

DEFINITION: A behavior is an algorithm designed specifically to generate the nu¬ 
meric input required by a feedback control system which will, in turn, produce a change in 
the underlying physical plant consistent with the desired primitive goal which activated the 
behavior. The term task is a frequently used synonym [Ref. 18] [Ref. 58], 

The satisfaction of a primitive goal may entail the execution of a set of related behav¬ 
iors. In some cases, behaviors may execute concurrently. In any case, the output generated 
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by these behaviors is numeric data in the form of setpoints and modes. These data collec¬ 
tively form the parameters required by servo loops to produce electrical signals that drive 
the associated servo controllers and actuators of the underlying physical system. 

Another approach to autonomous vehicle control involves problem decomposition 
based on a set of task-achieving behaviors. Conceptual levels are discarded in favor of lay¬ 
ers of control. Solutions are formulated through a subtle interaction of these layers. 

DEFINITION: A layer of control represents the realization of a single behavior or 
competence of the underlying system. 

A complete control software architecture may be built which comprises one or more 
of these layers. More complex levels of competence are achieved as additional layers of 
control are added. A layer, once activated, subsumes the role of the simpler layers lying at 
logically lower competence levels than the activated layer. 

D. SPECIFICATION OF THE RBM SOFTWARE ARCHITECTURE 

Like the examples of tri-level software control architectures described above, RBM 
utilizes the principle of abstraction to simplify the problem of mission control for an auton¬ 
omous vehicle. In fact, RBM utilizes several complementary abstraction mechanisms in 
each of its levels. The three levels of RBM, from highest to lowest degree of abstraction, 
are called Strategic^ Tactical, and Execution levels, respectively [Ref. 147]. Although these 
terms are not unique to this work [Ref. l8][Ref. 148][Ref. 154], they emphasize the con¬ 
ceptual abstraction of the levels when viewed as a whole. Defining characteristics of each 
level are listed in Table 1 for ready reference and are described in greater detail in the fol¬ 
lowing sections. 

The autonomous vehicles on which RBM is likely to be implemented wUl be required 
to accomplish missions that are best solved from a top down, goal-driven perspective. In 
recognition of this, the process of goal decomposition is handled naturally within the RBM 
hierarchy. The root goal, typically in the form of an overall mission objective, is decom¬ 
posed within the Strategic level. The resultant primitive goals of the Strategic level then ac- 
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Table 1: CHARACTERISTICS OFRBM 


Strategic Level 

• Symbolic computation only; contains mission doctrine/specification 
•No storage of internal vehicle or external world state variables 

• Rule-based implementation, incorporating rule set, inference engine, and working 
memory (if required) 

• Non-intemiptible, not event-driven 

• Directs the Tactical level through asynchronous message passing 

• Messages may be either commands or queries requiring YES/NO responses 

• Operates in discrete (Boolean) domain independently of time 

• Building block: the goal 

• Abstraction mechanisms: goal decomposition (RBM-B) and rule partitioning (RBM- 
F); both based on goal-driven reasoning 

Tactical Level 

• Provides asynchronous interface between Strategic and Execution levels 

• Behaviors (tasks) reside here and may execute concurrently 

• Behaviors are implemented as methods of objects 

• Primitive goals activate one or more behaviors 

• External interface of the model consists of two parts: the behavior activations from 
the Strategic level and the command/telemetry paths to/from the Execution level 

• World and Mission models maintained here 

• Responds to Strategic level with logical TRUE/FALSE 

• Setpoints, modes, active sensor commands, and non-routine data requests are output 
to the Execution level 

• Not interruptible except for data transfers; hard deadlines cannot be guaranteed 

• Operates in discrete event/continuous time domains 

• Building block: objects with behaviors 

• Abstraction mechanisms: class and composition hierarchies 

Execution Level 

• Numeric processing only 

• Responsible for software to hardware interface, underlying vehicle stability 

• All synchronous (hard real-time) processes reside at this level 

• Sensor data processed to specification of Tactical level 

• Servo loops run continuously and concurrently, synchronized by timed interrupts 

• Operates in continuous space/time domains 

• Building block: servo loops and signal processing algorithms 

• Abstraction mechanisms: loop composition, sampling frequency, and data smoothing. 
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tivate behaviors contained within the Tactical level. These behaviors are designed to pro¬ 
duce the actions required by the primitive goals, in part by generating the commands nec¬ 
essary for the proper operation of the servo loops ^ located in the Execution level, and in 
part by manipulating the state of the tactical level and comparing it with predetermined mis¬ 
sion subgoals and decision points. Finally, at the Execution level, the servo controllers are 
directed by the servo loops to manipulate actuators which cause changes in the relationship 
between the physical vehicle and its external environment. Various sensors then collect 
data to be ultimately used by the deliberative process contained in the Strategic level to 
guide future actions. 

1. Strategic Level 

It is apparent that the user of an autonomous vehicle must have an effective means 
of expressing a mission to the vehicle and, to some extent, the desired steps for carrying out 
the mission [Ref. 23][Ref. 55][Ref. 56]. The strategic level of the RBM architecture 
addresses this need directly by containing the explicit, high-level logic required to control 
an underljting robotic platform and the mission it is to perform. A customer who employs 
robots also requires that they behave predictably and efficiently; that is, the robot is 
expected to behave rationally. Seen computationally, global rational behavior is the 
realization of a deterministic sequence of simple actions resulting in some (possibly 
unobservable) side effects. Much recent research into so-called behavior-based 
autonomous control [Ref. 50] [Ref. 52] [Ref. 56] has achieved the desired global behavior 
by prioritizing primitive behaviors designed to compete with each other for the control of 
resources. A particular global behavior may be seen to emerge from these interactions, 
although typically at the expense of efficient operation and software modifiability. This 
latter weakness is a consequence of the global distribution of mission logic throughout the 
various behavioral layers comprising the architecture. 


1. Servo loops typically include both hardware and software. The term Execution level is reserved in 
this work for the software component of such loops only. 
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The hierarchical approach to autonomous vehicle control emphasizes a more 
procediu’al approach to system behavior sequencing [Ref. 43] [Ref. 155]. However, these 
systems also tend to suffer from the distribution of behavior-initiating logic throughout the 
architectme. Furthermore, the use of global blackboard-based data structures for interlevel 
communications is susceptible to undesired side effects linked to the execution history of 
the system [Ref. 99]. 

The primary strength of RBM, and one of its mziin contributions to the field of 
autonomous vehicle control, is the containment of behavior-sequencing logic at the upper, 
strategic level. The behaviors required for mission accomplishment are identified through 
the process of goal-driven decomposition. If the initiation of behaviors is expressed within 
a set of rules written in a rule-based programming language, the sequence of behavior 
activations can be controlled in a deterministic way through the use of a rule interpreter. In 
this approach, the function of insuring proper sequencing falls on the mission implementor. 

Because of the diverse educational and technical backgrounds which will likely 
characterize mission designers employing RBM, it is deemed essential that the mission 
expressed at the Strategic level be easily read, understood, and modified in response to new 
mission requirements. Reordering of behavior activations, introduction of new vehicle 
capabilities, and need for a finer degree of top-level control are all issues directiy affecting 
mission logic. In support of these requirements, and with an eye on involving the 
nonprogrammer in application development [Ref. 156], the implementation of the Strategic 
level of RBM must foUow some specific guidelines and restrictions. These important 
characteristics are listed here, along with the rationale supporting them. 

The basis for Strategic level design is the top-down decomposition of the mission 
based on goal-directed reasoning. As discussed in Chapter IV, this process involves the 
successive refinement of a root goal into constituent subgoals, continuing until simple, 
primitive goals are identified. These goals are not amenable to further simplification; 
instead, direct implementation is possible at this point. In this way, reasoning is restricted 
to the Strategic level with implementation relegated to the Tactical level. Because the 
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reasoning applied to the problem solution begins with the final goal and moves backwards 
to the circumstances supporting the solution, this process is called goal-directed reasoning 
[Ref. 115]. This approach to problem solving is best suited for autonomous vehicle control 
because all tasks and the sequence of their execution are explicitly identified. This is 
essential if the user of such a vehicle is to have confidence in the system and its abilities. 

Since the reasoning process typically results in a series of logical steps leading to 
problem solution, it is natural that the specification of the Strategic level be expressed in a 
manner suited to represent concepts of logic. Rule-based programming languages are 
ideally suited to this need and thus are to be utilized at this level of RBM. An obvious 
advantage is that the language is executable, averting the need for a separate translation of 
the mission specification into another language. A translation of this type would also forfeit 
the conciseness of the rule-based language while introducing complexity. 

During this phase of mission development, the use of state variables other than 
those necessary to support the reasoning process are to be avoided. This restriction has the 
primary purpose of insuring the simplicity and understandability of the mission logic and 
to enforce separation of the goals and their implementation. The Strategic level is 
responsible for determining the sequence of actions the vehicle should take, whereas the 
Tactical level is responsible for the implementation of those actions. As a consequence, 
computation at this level is purely symbolic. This is in contrast to the numerical processing 
which occurs at the lower levels of the architecture. 

Ultimate control of the vehicle resides with the Strategic level. The search of the 
rule set results in a call to the Tactical level for an initiation of a behavior. Each call is an 
instance of one of two types: a query or a command. A query is a request for information; 
however, because of the restriction on the use of state variables at the Strategic level, replies 
to these queries must be in binary form (i.e., TRUE/FALSE). Commands, on the other 
hand, are directives which expect no response other than an acknowledgment that the 
command either has been accepted or carried out to completion. Any feedback which may 
be subsequently required for decision-making is obtained through a process of polling 
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using queries. Again, simplicity and the isolation of reasoning from implementation are 
factors supporting this restriction. 

This emphasis on simplicity, at the expense of a greater degree of control, also 
requires that the Strategic level be free of semantic parallelism. Humans generally are better 
able to express concepts sequentially rather than in parallel. By placing this restriction on 
the Strategic level, the overall understandability of the implemented mission is assured, 
confidence in the rational global behavior of the system remains high, and subtle, 
undesirable effects caused by parallel interactions within the program are avoided. The 
benefits of parallel execution are not precluded, however, given that the parallelism is 
provided by the compiler/interpreter of the rule-based system. 

The rule interpreter operates independently of time. Therefore, the sequence of 
rule firings is driven solely by the search of the inference engine. When a primitive goal is 
encountered, the Strategic level waits for acknowledgment from the Tactical level before 
proceeding. Also, because the flow of control at the Strategic level depends on the logical 
truth or falsity of queries, operation at this level is in the discrete Boolean space domain. 
With the addition of the search mechanism imposed by the inference engine, the Strategic 
level acts as a sequential circuit, with the memory representing the state of the search. Put 
in this perspective, the expression of the mission becomes an exercise in propositional 
calculus (albeit with lazy evaluation), and the complexity of unification is avoided. 

A further characteristic of the Strategic level is that it be non-interruptible from 
within the RBM architecture. A thread of reasoning, realized through rule chaining, must 
be allowed to proceed to completion (i.e. to terminate at a primitive goal). Hence, the 
Tactical level cannot send commands to the Strategic level. Changes in mission state and 
vehicle environment are to be reported only when requested by the Strategic level. 

Given the above constraints, it is incumbent upon the mission specialist to strive 
for an accounting of aU non-time critical situations in which the vehicle may find itself. 
This is done using a common approach whereby categories of anomalies are identified 
which require similar responses. A one-to-many mapping is done between the members of 
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the finite set of responses and the anomalies contained in a category [Ref. 143][Ref. 144], 
To ensure full coverage, a primitive goal initiating a default behavior (surface, stop in 
place, etc.) should be included as a “last resort” alternative for each mission phase. 

Certain circumstances warrant immediate attention, however. Avoidance of 
collision or loss of the ability to maneuver are examples of conditions which must be 
responded to in a manner outside the normal query-decision-command cycle. These 
situations are best accommodated through the initiation of reflexive behaviors. This class 
of behaviors is designed to override existing control to avert problems affecting the safety 
of the vehicle. The Execution level, operating synchronously and responsible for the direct 
manipulation of the vehicle’s transport mechanisms, is best suited to carry out these 
behaviors in a timely fashion. Once initiated, control of the vehicle is wrested from the 
Strategic level until normal conditions are reestablished. It is conceivable that a return to 
total normalcy with respect to mission accomplishment is impossible, as would occur, for 
example, if a control plane on an autonomous submarine became inoperative. The degree 
of fault tolerance and recoverability of the vehicle in these circumstances depends on the 
application and design philosophy of the nndssion specialist. In any case, the mission logic 
contained at the top level must account for unanticipated events, either explicitly, as would 
be appropriate for mission replanning, or for cases when orders are disobeyed as a result of 
a reflexive behavior. 

Another scenario to be addressed relates to systems employing distributed 
multiprocessors as hosts for each level of control. Should communications between levels 
be lost, or if the commands or data from an adjacent level is determined to be erroneous, 
behaviors should be available to insure, at a minimum, the integrity of the vehicle. This is 
made possible through the isolation of responsibility within each level. The Execution level 
maintains the stability of the vehicle at all times. If commands from the Tactical level are 
interrupted, the vehicle remains stable. It may also be desirable for the Execution level to 
perform a recovery maneuver should commands not be received after a period of time. 
Likewise, the Tactical level should be endowed with behaviors whose purpose is to provide 
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sufficient direction to the vehicle following the loss of the Strategic level. In this way, 
hardware failures, while possibly jeopardizing the success of the mission, may not 
necessarily result in the loss of or damage to the vehicle. 

The potential for human intervention may be required in certain circumstances. 
Thus, even though the Strategic level cannot be interrupted from within, the possibility 
exists for external interruption if the inference engine executes in an interpretive mode, as 
opposed to a compiled executable module. Just as there are rules that query the Tactical 
level about the status of various vehicle subsystems, a rule may be included in the rule set 
to provide a check for receipt of messages from external sources. The success of such a rule 
could result in the activation of additional stored rule sets or perhaps even the receipt of a 
new mission. Interruptions of this type would typically be related to recall, mid-mission 
reconfiguration, or fail-safe procedures. 

The building block of the Strategic level is the goal. The logic of mission 
accomplishment through behavior sequencing depends solely on the relationship of these 
goals with respect one another. Individual goals are identified through goal decomposition 
based on goal-directed reasoning, concepts discussed in detail in Chapter IV. Once the set 
of primitive goals has been identified, the behaviors required to satisfy these goals will 
likewise be specified. The next step in the construction of the Strategic level is to express 
the logic in a symbolic, rule-based language incorporating a rule interpreter. The result of 
the interpreter’s search will be the expected sequence of primitive goals and their 
associated behavior activations. 

Originally, the strategic level of the RBM was defined to contain a concise, 
operational doctrine which described a top-level control strategy based on the avoidance of 
behavioral conflicts as opposed to the resolution of these conflicts [Ref. 147]. Specifically, 
the doctrine expressed the decomposition of the overall mission in terms of a goal tree with 
constraints on its traversal. Alternative branches of the goal tree could be combined to form 
an AND/OR search graph (see Chapter IV). This graph was then searched in depth-first 
fashion by a backward-chaining inference mechanism. TTie inherent ordering of the rules 
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as they were searched insured the avoidance of conflicts. Modifications to the overall 
behavior of the system could be accomplished by altering the logic of the rules or, more 
subtly, by changing the rule order [Ref. 23]. 

This approach to the executable representation of operational doctrine is a very 
powerful concept and as such will be retained in this work, in its entirety. The vehicle for 
which the original RBM was developed, the six-legged Adaptive Suspension Vehicle 
(ASV) [Ref. 44], was not autonomous in the purest sense, however. The Strategic level of 
the RBM employed on the ASV was primarily responsible for the coordination of limb 
motion based on free (non-periodic) gaits and consistent with some desired motion goal. 
These goals, in the form of vehicle motion commands, were provided by a human operator 
by means of a joystick. This configuration allowed for human control of three major axes 
of motion; forward velocity, lateral velocity, and turning velocity [Ref. 44]. 

Thus, the human operator of the ASV generated the high-level goals to be attained 
by the vehicle and provided the sequencing of those goals in support of mission 
accomplishment. The ASV’s Strategic level was then tasked to control leg motion in such 
a way as to satisfy the joystick command. The rule set describing this coordination was 
fixed, in that different missions did not require alteration of the Strategic level. Therefore, 
the term doctrine was applied to the code of the Strategic level, following the definition 
used by the military when referring to well-understood, well-documented strategies for the 
accomplishment of specific tasks. 

In the domain of autonomous vehicles, no human is available to provide the 
functions of determining goal attainment, identifying unreachable goals, and selecting 
alternative goals. These capabilities must be part of the Strategic level. In addition, these 
issues are mission related; that is, each mission may have unique success and failure criteria 
for the constituent phases of the mission along with detailed contingencies for each. The 
rules that contain this knowledge cannot be considered doctrine in the same sense as the 
ASV’s Strategic level doctrine. Instead, this portion of the Strategic level is collectively 
referred to as the mission specification. Whereas military organizations rely on doctrine to 
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realize generic functions, an operations order is issued to specify a unique mission tailored 
to some set of circumstances. Together, the operation order and the field manuals (doctrine) 
provide the guidance essential for the proper execution of a mission by a military unit [Ref. 
157]. Likewise, the mission specification and the doctrine make up the entire rule set found 
in the Strategic level of a RBM software architecture and contain the knowledge necessary 
for the autonomous vehicle to carry out its mission. 

DEFINITION: The Mission Specification is the part of the Strategic level 
containing the rule set embodying mission specific knowledge. 

DEFINTriON: The Doctrine is the part of the Strategic level containing the 
mission-independent rule set containing the logic required to solve problems not unique to 
the mission at hand. Doctrine is in general vehicle dependent. 

The addition of a mission specification to the doctrine does not alter the 
fundamental relationship between the Strategic and Tactical levels. This is not to say, 
however, that the doctrine is immutable. If a new mission involves strategies not addressed 
in the existing doctrine, the doctrine should be updated to reflect this. The analogy of 
military doctrine is consistent with this possibility, as all published guidance produced by 
the military is subject to review and revision to reflect changing missions. 

The abstraction that links the mission specification to the doctrine is goal 
decomposition. At some point, the subgoals derived firom the top-level mission goal will 
merge with the top-level goals of the doctrine. It should be emphasized that the inference 
engine used to search the composite rule set wUl not distinguish between the doctrine and 
the mission specification, and all rules wiU be represented within the scope of a single 
AND/OR goal tree. That is, the separation of rules into mission specification and doctrine 
is strictly for the purpose of human convenience and understanding. 

Because of the goal driven nature of this approach to the construction of the 
Strategic level, it follows that a backward chaining inference engine would be the ideal 
choice for an RBM implementation [Ref. 158]. Although this approach is indeed well 
suited for the large class of potential missions characterized by a backward reasoning 
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solution, the strategic level of RBM is not constrained to this one implementation 
paradigm. The forward chaining approach to mission implementation is commonly used in 
autonomous vehicle control applications [Ref. 45][Ref. 50][Ref. 56]. For this reason, we 
introduce two classes of RBM, distinguished by the type of chaining employed by their 
respective strategic level reasoners. The backward chaining, doctrine-based 
implementations of RBM are instantiations of the class RBM-Backward. 

DEFINITION-. The Rational Behavior Model-Backward (RBM-B) is a form of 
RBM characterized by a backward-chaining inference mechanism at the strategic level 
employing goal decomposition and an AND/OR goal tree as the basis for its search. 

The Strategic level of a member of the class RBM-B contains a rule set, composed 
of a mission specification and a doctrine, which essentially reflects the compiled logic a 
human operator would use to solve problems related to mission accomplishment; and a 
backward-chaining rule inference engine responsible for the orderly and logically 
consistent interpretation of these rules. 

The search performed by the inference engine is likely to involve repetition, since 
values returned from the Tactical level can change over time. In the context of mission 
execution, some search paths are designed to be continuously tried until success is reached. 
The notion of dynamic search is an extension of the usual notion of AND/OR graphs as 
static data structures [Ref, 137]. In applications involving autonomous vehicles in dynamic 
environments, dynamically changing data must be assumed. 

A second class of the Rational Behavior Model, RBM-Forward (RBM-F), 
includes implementations of the Strategic level still founded upon goal-driven reasoning 
but controlled using forward chaining. Forward chaining systems require that all states of 
the mission and transitions between these states be explicitly identified [Ref. 159][Ref. 
160], This class of software control architectures, RBM-Forward, is now introduced. 

DEFINITION: The Rational Behavior Model-Forward (RBM-F) is a form of 
RBM characterized by a forward-chaining inference mechanism at the Strategic level 
employing a state transition diagram to organize the sequence of allowable state transitions. 
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The strategic levei of a member of the class RBM-F contains three elements; (1) 
a rule set containing the rules which define the preconditions and postconditions associated 
with each transition between the members in the set of mission states; (2) a working 
memory containing the mission and vehicle variables necessary to uniquely identify the 
current state of the mission; and (3) a rule interpreter (a forward-chaining inference engine) 
which searches through the rule set, activating rules as the mission state warrants, and 
selects and fires a rule based on a well-defined conflict resolution strategy. 

The rule set found in the knowledge base of an RBM-F architecture does not share 
the explicit hierarchical structure of the AND/OR graph found in the RBM-B mission 
specification and doctrine. Hence, RBM-F mission implementations are, generally 
speaking, less concise and less understandable than the missions expressed in the RBM-B 
Strategic levels. However, the forward-chaining inference mechanism associated with the 
RBM-F class does employ a search structure in its execution of the mission. This structure 
is a state-transition diagram (STD), augmented with transition path priorities. An 
explanation of the STD is given in Chapter IV of this dissertation. 

The most general mission of the RBM-F controller is described by a traditional 
STD, which we call the mission STD. Here, the mission designer can configure the desired 
mission into phases, each phase represented by a state. Hence, the mission STD represents 
a top-level model of the mission and identifies the various phases of the mission (i.e., 
transit, search, track, etc.). These phases are subjected to a refinement process, whereby 
each state is “exploded” to reveal another STD. The lower-level STD contains the states 
internal to the parent state, including the appropriate conditions and actions for each 
transition. In many respects, the mission STD and the immediate partitions derived from it 
correspond to a mission specification of RBM-B. Beyond this point, the states identified 
through further partitioning correspond to the mission-independent doctrine of RBM-B. 
Eventually, the recursive partitioning of states results in the identification of final states. A 
final state represents the conditions necessary to perform interaction with the Tactical level. 
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It should be stressed that a final state in RBM-F is not equivalent to a primitive 
goal in RBM'B. A final state represents the set of conditions which must exist prior to the 
activation of behaviors in the Tactical level. These activations occur in concert with the 
firing of a transition out of the final state. In contrast, the primitive goal of RBM-B 
explicitly invokes the Tactical-level behavior from within the node. For this reason, 
additional states are needed for an exact translation between the AND/OR and STD 
structures. 

Conventional State Transition Diagrams require that state transitions be identified 
for all possible conditions and that these conditions be exhaustive and mutually exclusive 
so as to avoid nondeterminism [Ref. 136]. A state transition diagram describing a mission 
based on the forward-chaining RBM-F paradigm may involve states which have multiple 
successor states but transition conditions which are not mutually exclusive. This gives rise 
to a conflict, the resolution of which must be accomplished to insure the proper behavior is 
initiated. Since traditional STD notation does not make allowance for this, a prioritized 
state transition diagram is required to resolve these conflicts. Usually, conflicts that arise 
between competing behaviors are handled through a system of voting or the prioritizing of 
transition paths with respect to each other [Ref. 31][Ref. 52]. 

The state transition diagram with path priorities provides a convenient, graphical 
tool for modelling systems which exhibit “competing” entities. The term competing is used 
here to describe a scenario whereby two or more piocesses/tasks/behaviors request some 
resource simultaneously. Competing entities could then be represented by several paths 
emanating from the same state and with non-mutually exclusive transition conditions. 
Previous attempts have been made to partition conflicting behaviors through the use of state 
transition diagrams, most notably Bellingham’s State Configured Layered Control [Ref. 
56]. This model utilizes a single, top-level STD to partition the mission in much the same 
way as the mission STD is used. Further partitioning of the State Configured Layered 
Control STD is not performed, however. Instead, each state of the STD defines a subset of 
a layered control architecture [Ref, 31]. Hence, State Configured Layered Control does not 
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address conflict resolution at the same logically abstract level used to define the mission. 
Therefore, this approach suffers from the verifiability problems characteristic of 
behaviorist systems [Ref. 55]. 

Because the implementation of the reasoning used in the design of the Strategic 
level in both RBM-B and RBM-F is guided by some form of search graph, the inference 
engine must keep track of the current phase of the executing mission. The inference engine 
can be thought of as manipulating the state of the mission. This state refers to the facts 
available for use by the inference mechanism in its search of the rule set. Since backward 
chaining systems use a search algorithm based on rule position and depth-first traversal, no 
explicit state is required to determine rule priority. Forward chainers, conversely, apply 
search techniques which do not necessarily rely on positional relationships between rules. 
Instead, an explicit database of conditions, or facts, must be maintained. This fact base, 
representing the current state of the mission, determines which rules are to be activated at 
a given time. In any case, it is essential that the mission specialist be familiar with the 
particular search strategy employed by the inference engine. Mission development can then 
proceed based on this strategy and with the understanding that the inference mechanism 
will maintain the state of the search. 

The purpose of avoiding an explicit fact list (and global memory, for that matter) 
in RBM-B implementations and minimizing such a state in RBM-F implementations is to 
simplify mission development by abstracting the control problem to the maximum extent 
possible. Outside of the capability of expressing a mission in some rule-based language, it 
should not be presumed that the human mission speciahst is a computer scientist. In 
addition, comprehensive knowledge of the underlying computer systems architecture by 
this individual should not be assumed. 

The concept of the Strategic level of RBM is built upon the observed need for 
high-level logical control of complex autonomous systems. While this requirement has 
been met, the equally important issues of expressive power, understandability, and 
modifiability of mission logic have been addressed. Placing the constraints discussed 
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herein on the development of the Strategic level, while dramatic, is perceived as necessary 
if order is to be brought to the chaos of the “real” world. Once high level goals have been 
identified and their sequence of attainment specified, the vehicle must have the capacity to 
respond. This level of control is contained within the second of RBM’s three levels, the 
Tactical level. 

2. Tactical Level 

The middle level of RBM, like the middle levels of the three-level architectures 
mentioned earlier in this chapter, acts as intermediary between a knowledge-based 
behavior sequencing mechanism and the lowest level vehicle-control subsystem. A wide 
variety of approaches have been applied to the design of this level, from the competing 
behaviors of subsumption in SSS [Ref. 149] to discrete event modelling using Petri nets 
[Ref. 148]. The Tactical level of RBM further refines concepts from both these 
philosophies. Specific characteristics of this level are presented here, along with the 
justification supporting each. As with the Strategic level, certain restrictions are included 
as part of the architectural definition. 

The primary purpose of the Tactical level is to provide asynchronous coordination 
between the symbolic-based, behavior-enabling goals of the Strategic level and the 
numeric-based servo loops of the Execution level. To accomplish this, the Tactical level 
implements a finite set of behaviors. The result of a behavior may be a change to the 
internal state of the Tactical level, receipt and analysis of sensory data passed from the 
Execution level, a non-routine data request, or the transmission of commands in the form 
of numerical setpoints and modes as required for the proper operation of the Execution 
level subsystems. In addition, upon completion of a behavior, the Tactical level must 
respond to the Strategic level. This response may be explicit, as an answer to a query, or 
simply a return of control following the acceptance or completion of a commanded 
behavior. 
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The behaviors contained within this level of the model are non-logic based, 
repetitively executed processes, as compared to the rule-based reasoning of the top level. 
Behaviors may be thought of as being performed by one or more entities within the Tactical 
level. These entities, which possess a unique, defining, and persistent state, are referred to 
as software objects [Ref. 88]. A software object is essentially a finite-state machine 
producing a consistent output when an identical sequence of inputs is encountered, 
assuming the same starting state for each trial. A software design composed of a set of 
objects communicating with each other through well-defined interfaces is called object- 

based or object-oriented^ [Ref. 89]. Object-based and object-oriented design 
methodologies are explained in [Ref. 88] and [Ref. 94]. Formal specification of each object 
and the behaviors associated with each may eventually be accomplished using an approach 
similar to the Spec machine construct [Ref. 161]. 

Because the behaviors required of an autonomous vehicle resemble the 
functioning of a human crew on manned vehicles, an object-based design methodology 
whereby the functionality of objects correspond to that of individual crew members may be 
adopted for the Tactical level of RBM. This approach was used in the instance of RBM 
presented in the next chapter of this dissertation. Implementation of the various behaviors 
defined for the mission are divided among these objects. Some behaviors may require 
interaction between two or more objects. This interaction, as specified by the object-based 
design paradigm, takes the form of message passing. Receipt of a message results in the 
execution of a corresponding method defined within the receiving object. 

To enhance modularity and maintainability of the software, the objects of the 
Tactical level are organized in an object hierarchy [Ref. 88]. Child (dependent) objects are 
components of their parent object and can be accessed only through methods defined by the 

2. Object-oriented programming involves the concept of class inheritance: object-based programming 
does not Either is suitable for the implementation of the objects of the Tactical level. Both provide the 
advantages of ease of object instantiation, internal data and process encapsulation, and message passing. 
Object-oriented programming provides the additional feature of the class hier^hy, aDowing the reuse of 
boA variable and function definitions through the mechanism of inheritance. 
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parent. A child object has knowledge of its parent; hence, messages requesting services not 
contained within the child or its descendents must be sent to the parent for subsequent 
dispatch to other branches of the hierarchy. An exception is that data of a global nature (i.e., 
data required by several objects in the performance of their functions) may be obtained 
directly from an object designated to manage that data. 

The object residing at the top of the Tactical level object hierarchy has no parent 
and must serve as the interface between the hierarchy and the non-object-based world. All 
behaviors implemented in the Tactical level originate at this object. Behaviors are 
responses to primitive goals specified by the Strategic level. Therefore, the Strategic level 
communicates to the Tactical level solely through the interface provided by this object By 
way of analogy, the captain of a ship directs which goal is to be achieved. The goal is passed 
to the ship’s Officer of the Deck (OOD), who has the responsibility to insure that the goal 
is attained. The OOD assigns tasks to subordinates in support of the main goal. When 
completed, the OOD reports to the captain and awaits further directives. Note that the 
captain should not be involved in the implementation of behaviors, nor should he be 
involved in the direct control of the ship. In this scenario, the captain resides outside the 
realm of the ship’s operation. 

The Tactical level object hierarchy and the behaviors associated with it, together 
with the telemetry systems and servo control loops of the Execution level, constitute a 
functionally equivalent robot vehicle as viewed by the Strategic level. Behavior relating to 
navigation, system checking, sonar interpretation, and obstacle replanning are appropriate 
for the Tactical level. In order to isolate the reasoning process of the Strategic level from 
the vehicle-dependent Execution level, the Tactical level must provide for the complete 
monitoring and control of the Execution level while being guided by the primitive goals of 
the Strategic level. 

One characteristic of the Strategic level is its lack of knowledge of the operational 
environment, both external and internal to the vehicle. The purpose of this is to enhance top 
level simplicity, re-enterability, and consistency. The Tactical level, however, must base its 
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are behaviors whose execution times are functions of the environmental complexity and 
quantity of data to be assimilated. Some objects may require synchronous operation, such 
as the sensory receiver. For the most part, however, asynchronous operation is the norm; 
therefore, any process or task directly affecting the stability or safety of the vehicle must 
reside at the synchronous Execution level. 

The Tactical level implements the goals directed by the Strategic level by 
producing setpoints, mode changes, and data requests recognizable by control loops within 
the Execution level and which, when applied to these loops, will result in the desired 
change to the physical state of the vehicle. This transformation is accomplished through the 
initiation of behaviors manifested in the activation of objects. The objects contained in the 
Tactical level are organized into a tree structured hierarchy. By restricting inter-object 
communications to parent-child links, this hierarchy is inherently loop-free. Taken 
together, these characteristics enhance the understanding, maintenance, and software reuse 
at the Tactical level. 

3. Execution Level 

This level, called the “Servo” level within SSS [Ref. 149], “hardware control” by 
Saridis [Ref. 37], and “real-time” level by Blidberg [Ref. 39], is the best understood of the 
three levels of RBM. This derives from the fact that the body of knowledge constituting 
closed-loop servo control theory [Ref. 164] is mature, having developed over many 
decades. Hence, in most instances, the design and implementation of software at this level 
is accomplished by control engineers, not computer scientists. Indeed, this level is often 
taken more or less for granted by the researchers concentrating on the upper, more abstract 
levels of control. 

The Strategic level of RBM replaces the supervisory control provided by the 
human operator in remotely operated and manned vehicles. In some instances, human 
involvement in the control of a vehicle goes so far as to include direct control of thrusters 
[Ref. 165]. This degree of control requires that the human ROV pilot possess highly 


102 





developed hand-to-eye coordination and motor skills, similar to those possessed by a 
helicopter pilot. For autonomous control of vehicles, these functions must be provided 
within the RBM architecture. It is appropriate for the Execution level to provide these 
capabilities. 

Therefore, the Execution level of RBM must provide the means necessary to 
assure the underlying stability of the vehicle. Within the realm of autonomous underwater 
vehicles, this requirement is most easily satisfied through the application of at least the 

following: (1) a steering autopilot^ for heading control or rate control; (2) a diving autopilot 
capable of providing stable depth changes or control over pitch angle on command; (3) a 
speed control autopilot to adjust the vehicle speed in either a vehicle speed control mode or 
propeller rate mode; and (4) a hovering mode autopilot for maintaining position in a 
prescribed attitude [Ref. 166]. Land and air vehicles require specialized autopilots to 
provide the necessary stability, but whose purpose are the same. The internal 
implementations of these autopilots is unimportant as long as adequate robustness and 
stability of vehicle motion is guaranteed. 

By their nature, autopilots provide stability as long as the underlying servo loops 
are properly designed and continue to meet a prescribed update rate. This constraint may 
be met through the use of a fixed schedule triggered by timed interrupts from a real-time 
clock. Processes enabled in such a way are said to be time driven or synchronous. Rate 
monotonic scheduling guarantees efficient use of processor capacity in such circumstances 
[Ref. 167]. 

Commands must always be available for consumption by the autopilots. In 
vehicles operating in water or on smooth land terrain, these parameters may be provided by 
asynchronously executing objects in the tactical level. The robust nature of well designed 

3. Autopilots are devices that typically consist of a servo loop driving a servo controller. Setpoints are 
the input parameters to these loops. The setpoints differ depending upon the control mode selected. So, for 
example, a steering autopilot may operate in a heading mode, requiring input based on a geometric angle 
offset or in a rate mode, requiring input related to the desired turn rate of the vehicle. Autopilots for depth 
and speed may likewise operate in different modes. 
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following an upgrade to a sensor or a change in the fundamental capability of the robot to 
perform a given task. 

TTiere still remain many important problems to be solved at the Execution level, 
especially for vehicles which operate in three dimensions [Ref. 174] [Ref. 175] [Ref. 176]. 
In contrast to the operation of wheeled vehicles in a laboratory setting, where the servo 
problem reduces to control of wheeled rotation [Ref. 54] [Ref. 149], the seemingly simple 
task of remaining stationary with respect to a given coordinate frame (i.e., station-keeping) 
is a very difficult problem for underwater vehicles. Unmanned airborne vehicles have their 
own unique stability problems [Ref. 177]. 

E. SUMMARY 

The Rational Behavior Model provides important advantages over existing approach¬ 
es to software development for the control of complex, autonomous vehicles, while allevi¬ 
ating or ameliorating some of their distinct disadvantages. As such, RBM provides a more 
powerful and versatile framework for the construction of these increasingly complex soft¬ 
ware systems. Versatility results from the isolation of responsibility inherent in each level. 
This conceptualizing is carried over to the design of the architecture, primarily through the 
association of specific programming paradigms to each level. Selection of computing hard¬ 
ware, operating systems, and implementation language is guided by product availability 
and the experience of the designers. 

RBM is also powerful with respect to the software maintenance of an existing system. 
Reasoning related to mission accomplishment resides only in the Strategic level; behaviors 
which carry out the goals of the Strategic level are located in the Tactical level; and syn¬ 
chronous processes responsible for stabilization of vehicular motion, hardware manipula¬ 
tion, reflexive behavior, and basic telemetry processing fall within the scope of the Execu¬ 
tion level. 

In addition, use of the object-oriented design methodology at the Tactical level enforc¬ 
es modularity, data and procedural encapsulation, and formalized interfaces within soft- 
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ware objects. Finally, modification of the software of one level need not affect adjacent lev 
els. A well-defined, inter-level communications interface, terminated by single data “gate 
ways” insures that commands and data are available to those processes requiring them. 





VI. ARCHITECTURE VALIDATION 


A. INTRODUCTION 

This C " ses the practical issues related to the design and implementation of 

the Rational ijenavtor Model. Chapter V provided a description of the attributes which 
characterize an instantiation of RBM, independent of the application, vehicle, or computa¬ 
tional configuration. By insuring that these attributes are not violated during implementa¬ 
tion, designers of autonomous vehicles who choose RBM as their control software archi¬ 
tecture may expect to benefit from the model’s advantages while still being afforded a rea¬ 
sonable amount of flexibility in terms of developmental decision making. Of course, this 
flexibility will certainly not prevent the consequences of a poor design and the resulting un¬ 
anticipated or unacceptable performance. 

What follows is an example implementation involving the simulation of a small Au¬ 
tonomous Underwater Vehicle executing a real-world mission under RBM control. The dis¬ 
cussion begins with a review of the issues a control software systems designer must con¬ 
front when considering the resources required to best support the vehicle’s capability and 
the class of missions that will be expected of it. These issues include the degree to which 
concurrency and real-time execution are needed; the available hardware resources and their 
configuration; and the programming languages and operating systems selected for the im¬ 
plementation. 

As an introduction to the experiments and analysis which forms the rest of the chapter, 
the example mission is presented, followed by an explanation of the RBM instance con¬ 
structed to realize this mission. The model is then tasked to execute the mission on a labo¬ 
ratory simulator. The various data resulting from this experiment are examined and evalu¬ 
ated, and conclusions are drawn. 
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B. IMPLEMENTATION CONSIDERATIONS 


Development of the control software architecture for an autonomous vehicle is strong¬ 
ly influenced by the hardware and software resources on hand, the experience of the pro¬ 
grammers, and the characteristics of the missions assigned to the vehicle. Resources in this 
context include the number and type of processors, memory, communications facilities, and 
other assorted hardware support; the capabilities of the operating system(s); the existence 
of pre-written software modules; and the availability of languages and software develop¬ 
ment tools. This section reviews the practical issues of implementing a software architec¬ 
ture with respect to languages, operating systems, real-time constraints, concurrency, and 
distributed computing. 

1. Languages 

The major programming paradigms were examined in Chapter III. While each 
paradigm has applications for which it is well suited, programmers of autonomous vehicles 
should not be expected to be “fluent” in every one. Additionally, the project’s budget may 
not allow for the purchase of representatives of each class of programming language along 
with the associated compilers, editors, design tools, etc. 

Nevertheless, the choice of RBM as a control framework implies a multi-para¬ 
digm approach. Besides the advantages of this architecture (as enumerated in Chapter V), 
this requirement is necessary to insure the desired isolation and separation of responsibili¬ 
ties between the disparate levels. The expressive power of each language and the potential 
for simplified software modification resulting fi-om this design are sufficient reward to jus¬ 
tify any initial “start-up” costs associated with the purchase and learning of a new language. 

One additional potential cost involved with the use of multiple programming par¬ 
adigms is designing the interface between them. The capability of invoking “foreign” lan¬ 
guage calls from within a program is not always provided for by the particular compiler/ 
interpreter on hand. Since each language has its own parameter passing and variable typing 
conventions, a separate interface must be built for each. For example, the version of Quin- 
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tus Prolog used for the implementation of the Strategic level described in this chapter pro¬ 
vides pre-defined protocols to call C, Pascal, and Fortran routines [Ref. 178]. Since Ada 
was chosen as the language for the Tactical level, the Prolog-Ada interface had to be con¬ 
structed from scratch. Furthermore, the Execution level was written in C; therefore, an Ada- 
C interface also had to be built. This topic will be elaborated in the discussion section of 
this chapter as it is an essential, although implicit, component of the architecture. 

2. Operating Systems 

The services provided by an operating system may be quite diverse and, as such, 
are often tailored to a particular application [Ref. 106]. Support provided by the resulting 
“executive” or “kernel” may include real-time job scheduling, multitasking, communica¬ 
tions, memory management, and exception handling. Of course, operating systems are soft¬ 
ware programs themselves and therefore must share the memory and processor with the ap¬ 
plication programs. In the past, these resources were scarce, and the responsibility of pro¬ 
viding these services fell upon the programmer. In addition, the control software was 
typically generated and compiled off-line and the resulting object files subsequently ported 
to the target computer. The programmer would then initiate the control program by loading 
the appropriate registers prior to execution [Ref. 179]. 

The need for efficiency, particularly in applications involving real-time execution 
requirements, has also resulted in software control system designs lacking a traditional op¬ 
erating system. Recently, however, operating systems have been introduced that explicitly 
address real-time concerns [Ref. 170][Ref. 180]. These products, combined with the simul¬ 
taneous reduction in cost and increase in speed of hardware, have relegated the decision re¬ 
garding operating systems with respect to autonomous vehicles to one of convenience rath¬ 
er than of performance. 

Still, the actual operating system(s) selected will depend heavily on the require¬ 
ments placed upon them. The DOS family of operating systems are general in scope and 
perform efficiently but do not provide multitasking. UNIX does support multitasking but 
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cannot guarantee the scheduling necessary to meet real-time deadlines. While less prob¬ 
lematic, a version of the desired implementation language that is also compatible with an 
existing operating system may not be available. For the implementation described herein, 
versions of Prolog and Ada were available for use with UNIX but not for IRIX, the operat¬ 
ing system of the Silicon Graphics Iris workstations. Hence, at a minimum, two separate 
processors and two different operating systems were needed for this instantiation of RBM. 
Of course, RBM is not constrained to any specific language/operating system combination. 

3. Real-time Constraints 

Processes whose measure of “correcmess” is a function of time as weU as accept¬ 
able output are classified, with the entities that they control, as hard real-time or, more sim¬ 
ply, real-time systems. Should these systems fail to meet a deadline imposed upon them, 
even if the output produced is computationally correct, serious consequences involving ve¬ 
hicle integrity or damage to objects in the vehicle’s immediate vicinity may ensue. Typi¬ 
cally, real-time processes are used to insure the fundamental stability, prevent imminent 
collision, and respond to internal failures of the vehicle. 

Within the RBM framework, all real-time processes reside in the Execution level. 
Once the various tasks have been identified and implemented, a scheduling policy must be 
generated. It is the responsibihty of the real-time scheduler to insure that the processes are 
dispatched in a sequence which meets all deadlines. 

The deadlines under which the real-time control processes of the NFS AUV exe¬ 
cute are based upon the receipt of timed interrupts. Each interrupt signals a process to com¬ 
mence. It is therefore necessary for the previous process to have completed its tasks prior 
to the commencement of the next. By analyzing the execution times of each process sepa¬ 
rately along with the system “overhead”, if applicable, the adequacy of the schedule to meet 
all constraints can be verified. 
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4. Concurrency 

The definition of the Tactical level of RBM states that this level shall be com¬ 
posed of software objects that communicate via a message passing mechanism. A signifi¬ 
cant provision of this design is that some (or aU) of the objects may be active at a given 
time; that is, several objects may embody separate, distinct threads of control. On a single 
processor, logical concurrency of these objects is realized through the “interleaving” of 
each task’s execution under the guidance of a time-sharing or priority-based algorithm. If 
multiple processors are available to support true parallel execution, objects may run simul¬ 
taneously. In either case, the actions of each are coordinated through the sending of mes¬ 
sages to one another. 

Concurrency may be provided in several ways. A multitasking operating system 
can emulate parallelism on a single processor. On transputers or other multi-processor plat¬ 
forms, the operating system or programmer can assume the responsibility for the efficient 
assignment of tasks to available processors, a technique called load-balancing [Ref. 107]. 
In this scenario, the benefits of concurrent execution must be weighed against the time 
spent dividing the problem and assigning each piece to a processor. Needless to say, load 
balancing is not an attractive alternative for ill-defined, unstructured problems. 

Another approach to concurrent execution is to utilize control constructs provided 
by a concurrent programming language. This allows for the explicit identification of poten¬ 
tial parallelism within the program, although multiple processors, and a scheduler capable 
of assigning the tasks to the various processors, will still be necessary to realize an increase 
in performance. Ada provides these features and was therefore selected for this work. Al¬ 
though not used in this particular implementation of RBM, it is expected that future exten¬ 
sions to this instantiation will call for concurrent processing. 

5. Distributed Computing 

One approach to the employment of multiple processors is through a distributed 
network of computers. As mentioned earlier in this section, the implementation of RBM 
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discussed in this dissertation required that a multiprocessor solution be used. The proces¬ 
sors, in the form of separate workstations, were distributed in that they executed simulta¬ 
neously with respect to each other. In this case, message passing occurred over communi¬ 
cations channels provided by an Ethernet link [Ref. 181]. The processors in this network 
were loosely coupled, in that each had access to its own private memory (in contrast, a con¬ 
figuration in which separate processors share a common memory area is called tightly cou¬ 
pled). Inter-processor communication is a significant issue regardless of the configuration, 
but one for which solutions are generally available [Ref. 182]. 

A distributed system complements the emphasis placed by RBM on the isolation 
and divided responsibility of each level of control. As such, designs calling for the assign¬ 
ment of each level to a separate operating environment are feasible. For instance, a Strate¬ 
gic level written in Prolog, executing interpretively and running on a UNIX-based process¬ 
ing platform can pass commands to and receive replies from a Tactical level designed as an 
object hierarchy, implemented in Ada, and running on a second UNIX-based computer. Fi¬ 
nally, this Tactical level can issue commands to an Execution level written in yet another 
language and hosted on a third processor. Alternatively, the Strategic and Tactical levels 
can both execute concurrently on a single processor while the Execution level resides on a 
separate host The flexibility of this design is obvious, despite the implementation restric¬ 
tions placed on it by the definition of RBM. The three processor network described above 
was used for the instantiation of RBM discussed in the following sections; the two proces¬ 
sor configuration, on the other hand, reflects the design of the computing facilities on the 
actual NFS AUV [Ref. 72]. 

C. THE MISSION 

During the spring of 1992, a workshop [Ref. 183] was convened at the Florida Atlantic 
University under the sponsorship of the National Science Foundation to discuss and ad¬ 
vance the state of autonomy within the field of underwater vehicle technology. The work¬ 
shop participants recognized the importance of cooperation and collaboration among the 
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members of the Ocean Technology community as a way to focus efforts toward the attain¬ 
ment of common goals. Among the recommendations presented in the workshop results 
was the use of inter-institutional technology demonstrations to evaluate the effectiveness of 
current research concepts. To this end, three sample AUV mission scenarios were selected, 
each containing significant challenges and sufficient realism to insure that even partial task 
completion would insure valuable experimental results. The three task scenarios selected 
were search and rescue, pollution source location, and navigation with obstacle avoidance. 
Each mission provides a realistic basis for the employment of autonomous underwater ve¬ 
hicles. 

The scale and scope of these missions make them ideal for the experimental validation 
of any control software architecture. Each mission requires the demonstration of important 
capabilities expected of an AUV. Taken together, these capabilities include search, survey¬ 
ing, sampling, obstacle classification and avoidance, and payload management. Implicit in 
each mission is the obvious need to maintain vehicle stability, to navigate satisfactorily in 
a dynamic environment, and to provide provisions for the safety of the vehicle. For the pur¬ 
pose of this research, one mission, search and rescue, was selected as a test case for evalu¬ 
ation in this chapter. All of the missions are listed in Table 2 

D. INSTANTIATION OF THE MODEL 

This section discusses the implementation of RBM using a simulation of the NFS 

1 

AUV as the underlying vehicle and the search and rescue scenario as the mission to be ac¬ 
complished. Strategic and Tactical levels were constructed for this research with this mis¬ 
sion in mind. A non-linear, hydrodynamicaliy accurate model of the NFS AUV has been 
previously developed jointly by students &om the Computer Science and Mechanical En¬ 
gineering departments of NFS in support of vehicle testing in the NFS pool [Ref. 184]. This 
simulation contains all the essential characteristics of an RBM Execution level, including 


1. This mission has come to be known as the Florida mission because the ^monstrations are scheduled 
to take place off the Florida coast. 
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Table 2: THE THREE FLORIDA MISSIONS AND THEIR REQUIREMENTS 


Mission 1: Search and Rescue. Given the parameters of a search region, the AUV will 
traverse to the region, locate a subsurface buoy, cut the buoy’s mooring line, drop a 
weight as close to the buoy as possible, return to the launch site, and surface. 

Mission 2: Navigation and Obstacle Avoidance. The AUV transits to its starting posi¬ 
tion. At start time T, it transits to waypoint #1 where it releases a marker at T+5 min. 
The AUV proceeds toward waypoint #2 choosing to either: avoid the target area 
entirely; or to identify and locate the relative position of all targets within the target 
area, proceed to the position represented by the centroid of the shape formed by the tar¬ 
gets, and drop a marker at that point. In either case, the AUV will arrive and drop a 
marker at waypoint #2 at T+15. The AUV will proceed towards waypoint #3, choosing 
to either; avoid the obstacle area altogether; or to enter the area and avoid the barrier. In 
either case, the AUV will arrive and drop a marker at waypoint #3 at T+20. The AUV 
will then return to its starting point, arriving as close to T+25 as possible. 

Mission 3: Pollution Source Localization. The AUV wiU be launched from shore, 
downstream of the pollution source. The AUV will transit upstream using depth con¬ 
tour. The source of pollution (either acoustic signature or florescent dye) will be located 
and a beacon deployed. The AUV will then move to an exit point on shore. 


models of the guidance, depth, and speed control autopilots, vertical and directional gyro¬ 
scopes, and a synchronously updated control loop. Each level of the resulting RBM is de¬ 
scribed in detail below, and discussion concerning implementation choices and the ratio¬ 
nale behind each is included when appropriate. To provide closure with the discussion on 
forward and backward chaining presented in Chapter IV, both forward and backward chain¬ 
ing Strategic levels for this mission have been implemented and are compared. 

1. Strategic Level 

The set of primitive goals associated with the Florida mission and the sequence of 
their execution results from an application of goal-driven reasoning by the mission devel¬ 
opers. Each mission originates with a single high-level goal, such as search and rescue. This 
top, or root, goal is then reduced by introducing simpler but more specific subgoals. Taken 
together, these subgoals will satisfy the root goal. In the search and rescue mission, the 
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problem reduces to having the AUV traverse a path from the launch site to a specified lo¬ 
cation, search for and locate a subsurface buoy, perform a simple task to mark the location 
of the buoy, and return to the launch site. These subgoals are subject to further decomposi¬ 
tion, depending on the degree of control desired at the top level. A Strategic level derived 
from an overly thorough refinement of the goals is analogous to a human micro-manager, 
whereas one based on a coarser decomposition and providing more general primitive goals 
to the Tactical level would reflect a “hands-off’ management style. Of course, this would 
necessitate a more complex implementation of the corresponding behaviors at the Tactical 
level. In any case, the reduction proceeds until subgoals of sufficient simplicity result 
which lend themselves to implementation. This completes the reasoning portion of the mis¬ 
sion planning process. 

The next step is to implement this mission. Two possible approaches are investi¬ 
gated in this work: backward chaining and forward chaining. Since the Rational Behavior 
Model as defined can accommodate both approaches, an example of each is investigated. 

a. The Backward Chaining Implementation 

The goal-driven solution is naturally suited to a backward-chaining imple¬ 
mentation (Ref. 46]. For this purpose, the logic programming language Prolog was select¬ 
ed. Prolog offers an additional advantage in that it provides a control mechanism called an 
inference engine to search the set of rules. As a result, the inference engine determines the 
sequence of primitive goals and, thus, the order of behavior activations. Although the Pro¬ 
log programmer is not concerned with the details of the inference engine, how it works 
greatly affects the resulting structure of the program. This stems fi'om the fact that Prolog 
uses depth-first search in its traversal of the rule set. 

Prolog provides the basic constructs of facts, rules, and queries found in rule- 
based languages. These clauses can form the basis of sophisticated expert systems whose 
purpose is to reason about the problem and select the best solution from a set of alternatives. 
The logical relationships upon which these decisions are made are embodied in the Prolog 


116 



rules. Each rule expresses an implication or if-then relation. As shown in Figure 8, the if 
part of the Prolog rule, or body, lies to the right of the symbol and can consist of one 
or more subgoals linked through the logical AND operator. In Prolog, AND is represented 
by a comma. The then part of the relation, or head, lies on the left of thedelimiter (read 
as “if’). Left sides of rules are restricted to one term only, a characteristic of the Horn clause 
form, as discussed in Chapter IV. 



The goal residing on the left side is considered to be satisfied only when all 
subgoals on the right side have been satisfied. The Prolog inference engine attempts to sat¬ 
isfy each of these subgoals in order from left to right. Because multiple subgoals are logi¬ 
cally connected by AND, the failure of any one results in the failure of the rule. Evaluation 
of that rule stops when a failure is encountered, a technique known as lazy evaluation. 

Rules which share identical left sides are related to one another through the 
logical OR operator. In this case, if one rule fails, the next rule will be evaluated, and so on, 
until a related rule succeeds or until no more rules sharing the goal remain. Again, lazy 
evaluation stops any further search of the related rules once the goal has been satisfied. Be¬ 
cause Prolog scans the rule base fiom top to bottom, rules related by an OR should be or¬ 
dered with respect to one another to reflect their respective priorities by placing the highest 
priority rule at the top of the group and the lowest priority rule at the bottom. 

Prolog always attempts to satisfy a subgoal by matching it to a fact or rule 
head. When a match is found, the process proceeds to the next subgoal in the rule and an- 
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other match is attempted. The inference engine guiding the search marks each goal to pro¬ 
vide a reference should the current inference chain fail. If a match cannot be made given 
the existing circumstances, an attempt to resatisfy the previous subgoal is automatically 
done through a control mechanism called backtracking. If no subgoal can be satisfied, the 
corresponding rule is skipped and an alternative rule is selected, if available. 

Prolog provides the built in control flow primitive repeat which, when used 
in concert with backtracking, allows for the creation of loops. When first encountered, the 
repeat succeeds and the loop is entered. The repeat subsequently succeeds when encoun¬ 
tered through backtracking. This provides for multiple attempts to satisfy those subgoals 
lying to the right of the repeat. 

Another control primitive is required to insure a strict, iterative loop. This is 
the cut, denoted by “!”, which acts to block backtracking. In the context of RBM, the cut is 
used to eliminate internal cycles and to force a specific sequence of behavior activations. 
While the use of these control flow predicates compromises the program from the stand¬ 
point of pure logic programming, they are essential if unwanted backtracking is to be avoid¬ 
ed. 

Reference is now made to the Prolog implementation of the Strategic level for 
the search and rescue mission given in Appendix A-1. Since a backward-chaining language 
is being used, this instantiation is a member of the class of RBM-B architectures. The pro¬ 
gram is initiated when the query “?-execute_auv_mission.” is issued to the Prolog inference 
engine. Scanning the heads of each rule from the top of the rule set to the bottom, the rule 
“execute_auv_mission :- initialize, repeat, mission.” is encountered. Prolog will first at¬ 
tempt to satisfy the subgoal “initialize”. The rule set is scanned, again from the top, for a 
matching rule head. Two initialize rules exist, although the rule “initialize vehi- 
cle_ready_for_launch_p(ANSl), ANSI == 1, select_first_waypoint(ANS2).” has priority 
because it is encountered first. 

The subgoal “vehicle_ready_for_launch_p(ANSl)” is an example of a prim¬ 
itive goal; that is, it is a goal not subjected to further decomposition. Primitive goals mark 






the interface between the Strategic and Tactical levels and may represent requests for in¬ 
formation or commands. A request expects a response that can take on values representing 
TRUE or FALSE. This value in turn influences which one of several alternative reasoning 
paths is taken by the inference engine. A command, on the other hand, is a directive that 
may or may not expect a response other than an acknowledgment that the task was initiated 
or accomplished. The variable ANS (for ANSwer) associated with each primitive goal ac¬ 
cepts the Boolean value returned from the Tactical level and is then available within that 
rule for comparison. 

An implementation detail associated with the use of Prolog with foreign lan¬ 
guage calls is the requirement to supply return variables in every case. In the program under 
discussion, the primitive goals are actually making calls to C routines written to support the 
communications link between the two workstations hosting the Strategic and Tactical lev¬ 
els. The C routines then pass the desired goal over the network where it is accept by the 
Tactical level. Although some primitive goals are not followed by a comparison and that 
value will be discarded, the variable is still required as part of the function call acknowl¬ 
edgment. 

After the primitive goal invokes the appropriate behavior, the Strategic level 
must wait until a response is received. The Strategic level is, in effect, suspended during 
this time. If the behavior associated with readying the vehicle for launch is completed suc¬ 
cessfully, a TRUE (represented in the C programming language by the integer 1) is returned 
to the Strategic level and bound to the variable ANS 1. The primitive goal is then considered 
to be satisfied. Next, the retiun value is checked. If TRUE was returned, the comparison 
“ANSI == 1” succeeds and the next primitive goal, “select_first_waypoint(ANS2)”, is 
reached. If, however, the value of ANS 1 had been FALSE due to some failure encountered 
in readying the vehicle, the comparison would fail, causing the first “initialize” rule to fail. 
The inference engine would then select the second “initialize” rule. This rule involves a 
primitive goal commanding the Tactical level to alert the user, followed by a Prolog/a/7 
predicate that forces the failure of the rule. Since no other “initialize” rules exist, the “ini- 
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tialize” subgoal of the “execute_auv_mission” rule fails and, thus, so does the original que¬ 
ry, representing failure of the entire mission. 

Assuming the initialization process succeeds, the Tactical level is then com¬ 
manded to select the first waypoint. Once this behavior has been performed, the first “ini¬ 
tialize” rule succeeds. Prolog then returns to the “execute_auv_mission” rule and proceeds 
to the right in its attempt to satisfy all the remaining subgoals sequentially. The repeat pred¬ 
icate is encountered and succeeds automatically. This identifies the entry into the logical 
control loop consisting of the subgoal “mission”. There are four “mission” rules in the rule 
base, one for each phase: transit, search, task, and return. These rules are ordered so that the 
satisfaction of each will occur in the desired sequence. 

The first “mission” rule implements behaviors supporting the transit to the 
target area. First, a query “in_transit_p(ANSl)” is sent to the Tactical level to verify that 
the mission is truly in the transit phase. Although this may appear a bit unusual, it is neces¬ 
sary because the Strategic level cannot maintain an explicit state of its own and must rely 
on the Tactical level for status information related to the vehicle, the mission, and the en¬ 
vironment^. The response to the “in_transit_p” query is returned and bound to the variable 

ANS P, a comparison is done, and, if the mission is in the transit phase, the subgoal “tran¬ 
sit” is searched. 

Two “transit” rules are in the rule set. The first rule contains the “waypoint_- 
control” subgoal, and the other contains the “surface” primitive goal. The “waypoint_con- 
trol” subgoal is funher decomposed, as specified by the rule of that name, into a series of 
“critical_system_prob” checks, a waypoint status check, a planning sequence (if neces¬ 
sary), and a directive to issue new setpoint and mode commands to the Execution level. 


2, These restrictions result in Prolog code devoid of assert and retract statements, unification, and quan¬ 
tification. The use of variables is allowed only in conjunction with primitive goals (foreign fimcdon calls) 
and even then may only be of type Boolean. 

3. Similar variable names shared among different rules implies nothing. In Prolog, the scope of a vari¬ 
able extends only within the rule in which it resides. Therefore, when the search moves to a different rule, 
previously bound variables are not accessible. 


One “critical_system_prob” rule is included in the rule set for each vehicle 
subsystem which could, upon failure, jeopardize the mission. These rules, logically OR-ed 
together, each involve a query to the Tactical level relating to the status of one such sub¬ 
system. These systems are checked, in sequence, every time through the mission control 
loop. If one system is reported to have failed, the corresponding “critical_system_prob” 
rule will succeed. Returning to the “waypoint_control” rule, the truth of the subgoal “crit- 
ical_system_prob” is negated by the not predicate, a system-provided logical operator. 
Hence, a critical system failiue will cause the failure of the “waypoint_control” rule which 
in turn causes the “transit” rule to fail. However, if each “critical_system_prob” rule fails, 
the failure is negated within the “waypoint_control” rule causing the search to proceed to 
the “get_waypoint_status” subgoal. This subgoal consists of the logic needed to determine 
whether a Global Positioning System (GPS) reading is needed and, if it is, to obtain it. Next, 
the Tactical level is asked if the current wa 5 q)oint has been reached. If so, a command to 
select the next wa 5 /point is issued. The facts “gps_needed” and “get_waypoint_status” pro¬ 
vide for success by default for their respective subgoals. In other words, if the correspond¬ 
ing rules fail, then the subgoal will succeed when these facts are reached. 

The “plan” rules provide the logic for replanning the mission. The first plan 
involves global replanning as a result of reduced system capabilities. In this scenario, non- 
critical vehicle systems are checked which, if faulty, would not necessarily threaten the suc¬ 
cess of the mission. Instead, these faults would require a replan that may possibly result in 
a truncated mission or the relaxing of certain performance requirements. If global replan¬ 
ning is not needed, then the next “plan” rule checks whether an uncharted obstacle has been 
identified. If so, a local replan is performed. Note that the mles for both global and local 
replanning contain commands to initiate a “loiter” routine prior to performing the replan. 
By placing the vehicle in this mode, the Tactical level is free to concentrate its resources on 
the problem of replanning. It is conceivable, and probably desirable, to move some of the 
decision-making responsibilities of replanning to the Strategic level. The level of logical 
sophistication is determined by the mission specialist and probably depends on the com- 






plexity of the replanning schemes to be used. If neither type of replanning is required, a 
“plan” fact is included to represent the nominal operating condition and to insure the suc¬ 
cess of the “plan” subgoal. 

Once the “plan” subgoal has been satisfied, one last subgoal of the “way- 
point_contTor’ rule must be satisfied. This subgoal is the primitive goal “send_setpoint- 
s_and_modes(ANS)” and whose intent is to direct the Tactical level to issue the new com¬ 
mand packet to the Execution level. After the packet is sent, the Tactical level returns ac¬ 
knowledgment to the Strategic level, completing the evaluation of the “waypoint_controi” 
rule. 

Should the first “transit” rule fail due to the failure of the “waypoint_contror’ 
subgoal, the second rule will activate a behavior causing the AUV to surface. Surfacing is 
performed only as a last resort, but the inclusion of this rule is necessary to avoid an excep¬ 
tional condition for which the vehicle has no response. If, for instance, the first “transit” 
rule failed due to a systemic fault, and a second rule initiating the surface routine wasn’t 
available, the Strategic level would be “stuck” between the failure of the transit subgoal and 
the success of the repeat construct in the “execute_auv_mission” rule, producing an unac¬ 
ceptable infinite loop. 

Given that the various vehicle subsystems are healthy and a replan is not re¬ 
quired, the first “transit” rule will succeed. Prolog’s inference engine will return to the orig¬ 
inating “mission” rule and continue its attempt to satisfy the rule. When moving from left 
to right, the cut succeeds, and the next subgoal is investigated. Depending on the response 
to the primitive goal “transit_done_p” and the subsequent comparison, Prolog wiU either 
reach thtfail predicate at the end of the rule or backtrack to the last subgoal. In the former 
case, the transit phase has reached completion and \htfail forces failure of the first “mis¬ 
sion” rule. Prolog then searches for an alternative path to satisfy the “mission” subgoal. In 
the latter case, the “transit” phase has not yet completed, and backtracking commences 
from the comparison “ANS2 == 1”. Primitive goals, in their capacity as function calls, fail 
during backtracking and are passed over; therefore, “transit_done_p” is not retried. This 
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leads to an encounter with the cut. For the purpose of the search, this predicate identifies 
the point from which remaining subgoals are not to be reconsidered. In effect, the rest of 
the rule body is “cut” away, and Prolog wiU drop its attempt to satisfy the “mission” sub¬ 
goal. Backtracking then returns to the “execute_auv_mission” rule where the repeat causes 
Prolog to again attempt to satisfy the “mission” subgoal. 

The search, task, and return phases of the mission are completed in much the 
same way. Mission rules for each are structured similarly, in that a verification of the phase 
is made, followed by the logic relevant to that phase, and a check for phase completion. At 
the Tactical level, flags are maintained identifying the current state of the mission. The Tac¬ 
tical level is also responsible for recognizing the end of each phase. When a phase is com¬ 
pleted, the flag associated with that phase is reset and the flag for the next phase is set. As 
in the case of the transit phase, the other phases have two rules associated with them: one 
representing the normal case and one meant to deal with unrecoverable failures. For the 
purpose of this evaluation, any anomalies of this type result in the decision to surface. This 
alternative rule is always turned to as a last resort and, hence, is placed after its normal-case 
counterpart. 

When the return phase of the mission is completed, signified by a TRUE re¬ 
sponse to the “retum_done_p” subgoal of the fourth “mission” rule, the primitive goal 
“wait_for_recovery(ANS3)” is reached. This goal directs the Tactical level to place the ve¬ 
hicle in a state compatible with recovery. After this has been accomplished, the fourth “mis¬ 
sion” rule succeeds, satisfying the “mission” subgoal of the “execute_auv_mission” rule. 
Since all of its subgoals have been satisfied, ^yes response is given by Prolog to the original 
query “?-execute_auv_mission.”, indicating successful mission completion. 

The mission specialist responsible for programming the mission determines 
to what degree control is to be exercised from the Strategic level and the amount of respon¬ 
sibility to be delegated to the Tactical level. The primitive goals “do_search_pattem”, 
“start_local_replanner”, and “start_globai_replanner” are prime candidates for fiirther de¬ 
composition at the Strategic level. In addition, seemingly straightforward goals such as 





“surface” may need to be more precisely specified to account for circumstances in which 
the vehicle could behave differently to achieve the same goal (i.e., driving to the surface 
versus blowing ballast tanks). 

The clauses of the Prolog program in Appendix A-l have been divided into 
two groups marked “Mission Specification” and “NPS AUV Doctrine”. The purpose of this 
is to identify those rules which can vary from mission to mission (the Specification) and 
those of a more general nature which would be applicable for any mission (the Doctrine). 
This partition is purely to assist in human understanding. The inference engine views the 
entire program as a single rule set and searches it accordingly. 

b. The Forward Chaining Implementation 

The original goal-driven solution to the search-and-rescue mission may also 
be implemented using a forward-chaining approach. The resulting control architecture is an 
instantiation of the Rational Behavior Model with a forward-chaining Strategic level 
(RBM-F). As can be seen from the source code listing of Appendix A-2, a great deal more 
complexity is involved as compared to the backward-chaining example. The reason for this 
is twofold: (1) forward chaining rules are better suited to data-driven as opposed to goal- 
driven problems and (2) forward chaining solutions rely on the explicit identification and 
maintenance of the problem state space, tasks that were handled implicitly by the inference 
engine in the Prolog implementation. 

Regardless of the direction of the chaining selected for the Strategic level, the 
sequence of primitive goals attained during mission execution must be identical to that 
specified by the goal-driven solution. In terms of a forward-chaining system, this implies a 
particular sequence of state transitions. A State Transition Diagram is a graphical represen¬ 
tation of the relevant states of a problem and the relationships (or transitions) between 
them. 

In a forward chaining implementation, the rules represent the transitions. 
Each rule consists of two parts: a condition (or antecedent) and an action (or consequent), 







similar to an IF-THEN statement in an imperative language. If the condition side of a rule 
is satisfied by the current state of the problem, then the rule is said to be active. Should the 
actions specified by the consequent side of the active rule are applied, the rule is said to be 
fired. 

Except for final or “trap” states, each state has one or more successor states 
associated with it. If a single transition exists, the corresponding rule is fired which alters 
the facts (state) accordingly. When multiple transitions lead from the current state, the po¬ 
tential exists for a conflict. This occurs when the rules defining the transitions are simulta¬ 
neously active, and each must be investigated to determine which is to be selected for fir¬ 
ing. The resolution of these conflicts is generally the responsibility of an arbitrating entity 
(such as an inference engine). 

For this work, CLIPS (an acronym for C-Language Integrated Production 
System [Ref. 134]) was selected. CLIPS is a forward-chaining, rule-based expert system 
shell which mimics both LISP and OPS5, two languages whose features form the founda¬ 
tion of CLIPS, Another important characteristic that CLIPS shares with its predecessors is 
its use of the Rete pattern-matching and inference algorithm [Ref. 185]. The form of a 
CLIPS rule is shown in Figure 9. The antecedent of the rule lies on the left-hand side of the 


(defrule rule-name 

<conditiona]-e!ements> 



antecedent 


=> 


<actions>) 



consequent 


Figure 9. A CLIPS Rule 


production arrow (=>). The remaining portion of the rule resides on the right hand side of 
the arrow and is referred to as the consequent. The antecedent is a set of conditions which 
must be satisfied for the rule to be applicable. In CLIPS, the conditions of a rule are satisfied 
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based on the specified facts in the database (called the fact-list). The CLIPS inference en¬ 
gine matches the various conditions (patterns) against the current fact-list and determines 
which rules are applicable. Rules whose left-hand sides are matched by the facts are placed 
on the list of active rules called the agenda. CLIPS provides a full complement of logical 
connectives to relate multiple conditional elements. 

TTie consequent of a rule is a set of zero or more actions that are applied when 
the rule is executed. Rule firing, as well as the resolution of conflicts between active rules, 
is done by the inference engine. Whereas Prolog relied on depth-first search as its sole con¬ 
flict resolution strategy, the CLIPS system provides several possible strategies. Of particu¬ 
lar significance in this work is the facility provided by CLIPS to assign saliences (priorities) 
to the rules. In any case, the actions of the executed rule are performed, typically causing a 
change of state in the form of retracted and asserted facts. The new fact-list may in turn af¬ 
fect the list of applicable rules, causing new rules to be activated while other previously ac¬ 
tive rules are removed from the agenda. This cycle of rule selection and execution contin¬ 
ues until no applicable rules remain. 

Although similar in many ways to the procedural IF-THEN statements of im¬ 
perative languages, CLIPS mles are selected and remain active as long as their conditions 
are satisfied. In this way, any number of rules may be available for execution at a given 
point during problem solution. It is the responsibility of the inference engine to insure that 
the list of applicable rules is always kept current 

Within CLIPS, states are defined by sets of facts contained in the current fact- 
list These facts may be structured using the CLIPS deftemplate construct. The resulting 
fact template defines a group of related fields into which facts are placed. Each field may 
have associated with it an explicit type definition, a finite list of allowable values which the 
field can accommodate, and the defaxxlt value of the field. 

Appendix A-2 contains the forward chaining Strategic level code for the 
search and rescue mission written in CLIPS. The template definitions, which have been 
gathered together at the front of the program solely for ease of understanding, define the 
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relevant states of the goal-driven search and rescue mission solution. The goal-driven so¬ 
lution is the same one used to develop the backward-chaining implementation. However, 
in order to preserve the same sequence of behavior activations (or, equivalently, the same 
ordering of primitive goals), additional states reflecting alternative solution paths had to be 
defined. These alternative paths are enumerated in the “allowed-symbol” slot of the corre¬ 
sponding deftemplate. These templates are identified, in turn, by the inclusion of the prefix 
“or” in the label of the deftemplate structures. In affect, these templates provide the “traffic 
control” necessary to resolve conflicts between simultaneously active transition paths. 

The remaining CLIPS code for this implementation comprises the rule defi¬ 
nitions which are identified by the d^hile keyword. Each rule supports the attainment of 
some goal defined in the AND-OR goal tree produced by the goal-directed problem decom¬ 
position of the search-and-rescue mission. To assist in understanding, a particular labeling 
convention was used for these rules. As an example, the rule “waypoint-control- 13-s” is an¬ 
alyzed here. The name “waypoint-control” is derived directly from the goal of the same 
name. The first digit of the numerical suffix refers to the first (highest priority) path to sat¬ 
isfaction of this goal. In the case where alternative paths exist, this digit would range &om 
1 to the total number of paths. In Prolog, these alternatives are manifested in multiple rules 
which share identical left-hand sides. The second digit of the numerical suffix represents 
the target subgoal (state) whose satisfaction is currently being attempted. Continuing the 
example, the suffix 13 would refer to the transition to the third state (“plan”) of the first 
inference path of “waypoint-control” (of which there is only one). The letter “s” (for start) 
indicates that this rule involves the transition into the plan state; a letter “e” (signifying exit) 
would identify a rule whose firing would assert facts indicating the success of the goal as¬ 
sociated with that state. 

In the Prolog solution, a response corresponding to failure caused the infer¬ 
ence engine to halt its attempt to satisfy the goal specified by the head of the current rule. 
The search path would then proceed, in depth-first fashion, to the next rule containing an 
identically labeled head. By sharing the same rule left-side, these rules represented altema- 
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tive (ORed) solutions. In addition, the priority of these rules with respect to each other was 
determined by their placement in the rule set. 

An analogous prioritizing of OR-related rules does not exist in CLIPS. Tex¬ 
tual ordering of the rules is irrelevant; instead simultaneously activated rules are ordered 
based on their saliences. When a conflict occurs due to the existence of multiple state tran¬ 
sition paths, the transition (rule) with the highest priority is taken. Each subsequent rule fir¬ 
ing along that path may include a primitive goal whose purpose is to query the Tactical lev¬ 
el about the state of the mission or vehicle. The response to each query could potentially 
lead to the failure of this reasoning path. This in turn requires that the state of the OR-rela- 
tion be restored, allowing the alternative path(s) to be investigated. Restoration of these 
states is the purpose of the “traffic control” slot values within deftemplates containing the 
word “or” in their designators. 

Once the CLIPS environment is entered, the “(start)” fact is asserted onto the 
fact-list. The CLIPS inference engine searches all the rule left-hand side patterns to identify 
active rules which, when found, are placed on the agenda. In this example, the rule “exe- 
cute-auv-mission-lO-s” is activated because its condition is satisfied. Since it is the only 
rule on the agenda, it is fired, resulting in the retraction of the “(start)” fact and the assertion 
of the fact “(execute-auv-mission (state initialize))”. This fact represents the state which 
corresponds to the “initialize” subgoal of the execute_auv_mission Prolog rule. The CLIPS 
inference engine then searches the rule set, attempting to match this new fact against the 
condition patterns of the rules. The rule “execute-auv-mission-11-s” is then activated and 
it is fired. This results in the assertion of the fact “(initialize (state start))”. Again, the infer¬ 
ence engine searches the rule set, and the rule “initialize-lO-s” is activated and fired. The 
firing of this rule leads to the first of two alternative branches specified by the “or-initial- 
ize” template with its states “or_initialize_l” and “or_initialize_2”. 

At this point, the fact-list holds the two facts “(or-initialize (state or_initial- 
ize_l))” and “(initialize (state select_first_waypoint))”. The rule “initialize-11” requires 
these two patterns to satisfy its left-hand side, in addition to the primitive goal “ready_ve- 
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hicle_for_launch”. In order to determine if this condition is applicable, this query must be 
answered by the Tactical level. The response is then used in the “(test (= (ready_vehicle_- 
for_launch) 1))” expression. This involves the invoking of the function “ready_vehicle_- 
for_launch” (the same used in the Prolog implementation) which returns a Boolean value. 
The reserved word “test”, along with the “=” function, performs an equivalence compari¬ 
son between this response and the number 1. If the comparison succeeds, the rule “initial¬ 
ize-11” will fire. If, however, the comparison fails, the rule “initialize-11” will not be acti¬ 
vated; instead, the rule “initialize-10-e” is fired. This rule retracts the “(or-initiaiize (state 
or_initialize_l))” fact, breaking this inference chain, and establishing the alternative path 
by asserting the fact “(or-initialize (state or Jnitialize_2))”. This fact will lead to rules caus¬ 
ing the primitive goal “alert_user” to be attained. 

Presuming that the initialization phase of the mission is successful, the mis¬ 
sion rules are then considered. These rules correspond to the four phases of the search-and- 
rescue mission: transit, search, task, and return. In a manner similar to that describing the 
initialize rules, these rules are activated and fired based on saliences, attainment of a goal, 
and the results of queries. The functionality of the special Prolog control constructs repeat, 
!, and fail are emulated through the formulation of the left-hand side of each rule. 

To verify that the forward-chaining implementation did in fact produce the 
same side effects as the backward-chaining version, a trace of the sequence of primitive 
goals reached by each was collected for examination. The two versions of RBM did pro¬ 
duce identical sequences of behavior activations. The trace for a completed search-and-res- 
cue mission is found in Appendix A-3. Also included is a trace of an experiment involving 
the failure of the power supply of the vehicle. Traces such as these can be used to verify the 
mission logic upon which the Strategic level is instantiated, 

2. Tactical Level 

The Tactical level developed for this study is shown in Figure 10. This design was 
patterned after the watch crew of a manned submarine [Ref. 186], because the division of 


129 






Figure 10. Tactical Level Objects for the NFS AUV Florida Mission 

























responsibility and command relationships between parties was already well understood. 
Each block in the diagram represents a distinct entity within the organization and corre¬ 
sponds to a software object. Most of the objects are arranged into a hierarchy as indicated 
by the dotted lines linking them together. The AUV Officer of the Deck (OOD) resides at 
the top of the hierarchy and assumes overall control of the operation. In addition, the OOD 
provides the single interface between the Strategic and Tactical levels. Primitive goals from 
the top level are passed to the OOD who in turn activates behaviors known to the Tactical 
level and designed to satisfy those goals. Using the analogy of the watch crew, the Captain 
of the submarine issues commands to or asks for status reports from the OOD. The OOD 
then turns to his subordinates and issues the appropriate orders to satisfy the goal or query 
presented by the Captain. 

All the behaviors that are capable of being performed by the vehicle are embodied 
within the various objects of the Tactical level. The OOD must coordinate the actions of 
each object to insme each task is accomplished as expected. The behaviors, for their part, 
are reflected in the methods contained within the applicable object(s). Typically, a behavior 
will involve the interaction of multiple objects. Necessary inter-object communications are 
provided through the passing of messages. As depicted in Figure 10, direct communica¬ 
tions between members of the hierarchy is restricted to parent-child links. While this comes 
at the expense of efficiency, the benefits include the avoidance of unconstrained communi¬ 
cation paths and a greater degree of modularity. These characteristics support RBM’s em¬ 
phasis on providing a framework to the user that aids in the understanding and maintenance 
of the software at this level. 

Communications with the Execution level is likewise restricted. Commands, in 
the form of packets containing numerical set points and discrete mode changes, are issued 
only from the Command Sender object under the supervision of the OOD. Likewise, telem¬ 
etry data from the Execution level is received solely by the Sensory Receiver object. By 
constraining these interfaces, the potential for command conflict and data inconsistency is 
avoided. 
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Several objects at the Tactical level are not explicitly connected to the object hi¬ 
erarchy. These represent databases or data stores intended to be accessed by any requesting 
objects. The state of the mission, the environmental model, current sensor readings, and 
mission history are maintained and encapsulated within the corresponding objects. Re¬ 
quests for information and data updates are handled as they arrive; however, these objects 
do not participate in task accomplishment directly. 

The choice of an implementation language for this design was made from a range 
of object-oriented and object-based programming languages. The candidate languages con¬ 
sidered included Ada, C++, and CLOS. Each provide constmcts for data abstraction, infor¬ 
mation hiding, instantiation of objects, and, with one exception, inheritance. The exception 
is Ada, which does not support the concept of class hierarchies. However, Ada does provide 
the control prinnitives needed for concurrency which are not found in the other languages. 
This potential for parallelism, coupled with the availability of an object-oriented extension 
to Ada called Classic-Ada [Ref. 92], were the deciding factors in its selection as the lan¬ 
guage for the Tactical level. 

A brief description of each object is now given. This description will be limited 
to the purpose of the object as well as any significant or unusual characteristic which may 
be of interest to the reader. The source code use in this implementation, including the data 
structures, methods, and interface specification of each class can be found in the Classic- 
Ada source listing included in Appendix B. 

For the purpose of the evaluation that follows, the complete object hierarchy was 
instantiated. Not all behaviors, however, were fully implemented. Details of the individual 
behaviors (e.g. path planning and fault recovery) are not of primary interest here. Instead, 
the integration of these numerous and diverse behaviors is one of the fundamental require¬ 
ments of any software architecture and, hence, will be the focus of this investigation. 
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a. AUVOOD 


The OOD provides the sole interface between the Strategic and Tactical lev¬ 
els. Thus, this object, upon receipt of a primitive goal, must identify and activate the corre¬ 
sponding behavior(s) needed to satisfy that goal. Some behaviors may require the activa¬ 
tion of several objects. These activities, whether performed sequentially or concurrent with 
each other, must be coordinated by the OOD. 

The OOD has four immediate subordinates: the Navigator, the Engineer, the 
Weapons Officer, and the Command Sender. It is to these objects that the responsibility for 
supporting goal achievement is delegated. If these objects, or the dependents of these ob¬ 
jects, require services fi:om a sibling or dependent of a sibling, that request, in the form of 
a message, must be sent through the object hierarchy to the OOD. The OOD must then route 
the message to the appropriate subordinate. 

Commands to the Execution level are composed of a mode and setpoints 
specifying the desired heading, depth, and speed. These components are calculated by dif¬ 
ferent objects after which they are passed to the OOD. There, they are assembled into a sin¬ 
gle command packet and sent to the Cornmand Sender for subsequent passage to the Exe¬ 
cution level. 

b. Navigator 

The Navigator is primarily responsible for the current and future location of 
the vehicle. Hence, the tasks of guidance, position estimation, and path replanning fall un¬ 
der the purview of this object. Like the OOD, the Navigator is responsible for the dissem¬ 
ination of orders to its subordinates and the coordination of their actions. 

c. Guidance 

This object provides the desired heading setpoint which is eventually includ¬ 
ed in the command to the Execution level. This value may be obtained through the appli¬ 
cation of a guidance law, an algorithm that accepts parameters relating to current position, 
desired position, and environmental dynamics and produces a value corresponding to the 
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angle in which the vehicle needs to align itself. Several algorithms may be implemented, 
including line-of-sight (LOS), Cross Track Error, and variations for homing and hovering. 

For this research, a LOS guidance calculation was employed. When tasked to 
provide a new heading, this object performs the following calculation: 


'Ycmd = atan 


{Ynext-Y) 

{Xnext-X) 


where (X, F) is the AUV’s current location, (Xnext, Ynext) is the next waypoint to be 
achieved, and ^cmd is the angle between the reference and the line joining the two points. 
The result, in radians, is then converted to degrees, as expected by the steering autopilot. 

d. GPS Control 

The methods to activate, monitor, and take readings from the Global Position¬ 
ing System receiver are contained here. This system provides the ability to locate the posi¬ 
tion of the vehicle to a high degree of accuracy [Ref. 187]. Although this system is sched¬ 
uled to be implemented on the NFS AUV, its functionality was not included in this simu¬ 
lation. 

e. Sonar Control 

This object is responsible for the issuance of sonar commands, object identi¬ 
fication and classification, and estimating vehicle location based on this interpretation. This 
capability was not modeled for this study. Related research includes [Ref. 188]. 

/. Dead Reckoning 

The purpose of this object is to provide an estimate of the vehicle’s position 
based on a known position fix and the elapsed time since that fix. In the NPS AUV, dead 
reckoning output is required by the synchronous processes; hence, a separate dead reckoner 
is implemented in the Execution level. Although not essential, the Tactical level dead reck- 


134 







oner may be used as a way of checking the consistency and validity of Execution level op¬ 
eration. 

g. Mission Replanner 

Two types of replanning is performed by this object; local replanning caused 
by an uncharted obstacle and global replanning driven by a vehicle fault. Neither was mod¬ 
eled for this study. 

h. Engineer 

The Engineer monitors the health of the vehicle. Systems and conditions of 
interest include power, computer, propulsion, steering, diving, buoyancy, thrusters, pres¬ 
sure, and temperature. For this study, only the power system was modeled. 

j. Weapons Officer 

The primary concern of the Weapon’s Officer is the viability and delivery of 
the vehicle’s payload. No payload was modeled for this study. 

j. Command Sender 

This object accepts command packets from the OOD and transmits them to 
the Execution level. Since the Tactical and Execution levels are physically separated in this 
instantiation, the Command Sender incorporated the software necessary to perform net¬ 
work communications. Each command packet consists of the following: heading com¬ 
mand, depth command, speed command, and mode. Commands pertaining to latitudinal 
and longitudinal positioning are also sent; however, these relate to the AUV’s hover mode 
which was not used in these experiments. 

k. Sensory Receiver 

This object accepts telemetry records from the Execution level. Subsequent¬ 
ly, it extracts and stores individual data values and makes them available to other objects 
in the Tactical level. This object also affixes a time stamp on each sensory packet before 
sending the packet to the Data Recorder for archival purposes. In this instantiation, the Sen- 
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sory Receiver was synchronized with the Execution level at a 2 Hz transfer rate. Each sen¬ 
sory packet consists of a position given as (X, Y, ALT, depth) where X and Y are cartesian 
coordinates mapped to the NFS swimming pool, ALT is the distance above the floor pool, 
and depth is the current depth of the vehicle [Ref. 189]. 

L Mission Model 

This object contains the list of waypoints generated off-line by the mission 
planner, including the vehicle’s start and finish location. It also maintains the flags indicat¬ 
ing the current phase of the mission. For the purpose of this dissertation, methods and data 
structures are also included to support the initialization of the simulator. 

m. World Model 

This object contains maps, lists of known objects, and other data reflecting 
the vehicle’s operational environment that are available prior to mission initiation. 

n. Data Recorder 

This object maintains all telemetry records passed to it by the Sensory Re¬ 
ceiver, plus any additional messages designed to explain unforeseen or unusual events. 
Data is configured to best support post-mission analysis. Further details concerning these 
issues, as well as the communication interface incorporated within the Data Recorder, may 
be found in [Ref. 190]. 

3. Execution Level'* 

The instantiation of this level is patterned after the single loop controller imple¬ 
mented in the actual vehicle. Once the communications have been established and the sim¬ 
ulation initialized, the program runs in a continuous loop broken only by periodic data ex¬ 
changes with the Tactical level. Each pass through the loop consists of determining the 
depth of the water under the keel, checking the system clock for the next exchange with the 

4. The software for this level was written by S. M, Ong [Ref. 189], D. B. Nordman [Ref. 184], and D. 
Marco [Ref. 191]. 
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Tactical level, an additional clock measurement in support of the real-time graphics update, 
calculating vehicle dynamics and position based on the time since the last frame was drawn, 
and finally a redraw of the simulation frame. Communication with the Tactical level con¬ 
sists of the receipt of commands followed by transmission of telemetry. The target ex¬ 
change rate on the actual AUV is 10 Hz. However, due to the time required by the graphics 
portion of the program, a 2 Hz communications rate was realized in the simulation study of 
this dissertation. 

To provide realism to the simulation, the mass characteristics of the NPS AUV 
were modeled along with hydrodynamic coefficients for longitudinal, lateral, and normal 
forces as well as roll, pitch, and yaw. The vehicle model program calculates the dynamic 
equations of motion using readings from rudders, dive planes, and propeller rpm. The out¬ 
put is X, Y, and Z in world coordinates and the vehicle azimuth, elevation, and roll Euler 
angles. Drag force is calculated and integrated over the vehicle using four-term gauss 
quadrature. The resulting NPS AUV simulation is shown in Figure 11. 

E. EXPERIMENTS 

Complete instantiations of both the Rational Behavior Model-Backward and Rational 
Behavior Model-Forward were implemented. The Strategic level of the architecture, writ¬ 
ten in Prolog (for RBM-B) and CLIPS (for RBM-F), ran on a Sun SPARCstation 1 under 
the UNIX operating system. The interpreted rule set, derived from a top-down goal decom¬ 
position of the Florida search and rescue mission, is included for each form of RBM in Ap¬ 
pendix A. The Tactical level was written in Classic-Ada, an object-oriented extension of 
Ada. The Classic-Ada compiler produces “pure” Ada source code which is ready for com¬ 
pilation. Verdix Ada mnning under UNIX on a second Sun SPARCstation 1 was used for 
the generation of the executable modules. The Classic Ada source code listings are located 
in Appendix B. The simulation, implemented in the C programming language, ran on a Sil¬ 
icon Graphics 4D/24()VGX workstation under the IRIX operating system. The three work¬ 
stations were linked over an Ethernet connection. All communications was accomplished 
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Figure 11. The NFS AUV Simulation 

using stream sockets. Data values were converted into ASCII characters prior to transmis¬ 
sion and reconverted to their original 1)^)6 following receipt. The data was transmitted in a 
form whereby the data type and size was explicitly included. The software used to provide 
the communications support was written in the C programming language by Professor S. 
H. Kwak and is included at Appendix C. 

The first experiment involved the traversal of a figure-8 around the NFS pool. In order 
to better represent the four-phase Florida mission, the primitive goals “search” and “task” 
were assumed to be accomplished at the half-way point The “traversal” and “return” phas¬ 
es were represented by movement along the respective halves of the path. The results of a 
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typical time for the trial controlled by Prolog and CLIPS versions of RBM are compiled in 
Tables 3 and 4, respectively. 


Table 3: PERFORMANCE OF RBM-B IN TRANSIT PHASE 


Waypoint 

Time/Total 

(seconds) 

X position 
(in) 

Y position 
(in) 

Depth 

(in) 

Heading 

(degrees) 

(350,100,10) 

102/102 

332.93 

92.73 

9.61 

71 

(500,250,30) 

66/168 

488.78 

235.58 

28.75 

42 

(500,500,35) 

77/245 

500.63 

480.77 

33.82 

355 

(350,700,40) 

76/321 

363.38 

686.14 

38.53 

319 

(200,900,40) 

71/392 

211.95 

885.78 

38.40 

321 

(200,1150,12) 

78/470 

197.18 

1130.69 

13.36 

7 

(350,1300,20) 

66/536 

335.49 

1287.62 

‘ 18.81 

50 

(500,1150,30) 

81/617 

491.04 

1167.50 

28.88 

^ 154 

(500,900,40) 

77/694 

498.18 

918.40 

38.08 

178 

(350,700,50) 

77/771 

361.38 

715.22 

48.17 

219 

(200,500,50) 

71/842 

209.00 

516.68 

47.91 

211 

(250,150,50) 

104/946 

244.66 

169.22 

50.35 

166 


Associated with each waypoint is the time required by the AUV to reach it since the 
last waypoint, along with the total elapsed time of the run and the actual position and head¬ 
ing of the vehicle when waypoint attainment was determined. A waypoint was considered 
reached when the pythagorean distance between it and the center of mass of the vehicle was 
less than 20 inches. Although calculated using only two dimensions (X and Y), the vehicle 
was equally adept at maintaining the desired depth. 

The close similarity of performance between backward and forward chaining imple¬ 
mentations of the RBM indicate that both Strategic levels performed sufficiently to satisfy 
the 2 Hz update rate required by the Execution level. This implies that the complexity of 
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Table 4: PERFORMANCE OF RBM-F IN TRANSIT PHASE 


Waypoint 

Time/Total 

X position 

Y position 

Depth 

Heading 

(seconds) 

(in) 

(in) 

(in) 

(degrees) 

(350,100,10) 

104/103 

332.97 

90.92 

11.89 

63 

(500,250,30) 

66/169 

488.76 

235.36 

28.63 

41 

(500,500,35) 

78/247 

499.31 

480.06 

33.73 

359 

(350,700,40) 

77/324 

362.75 

685.41 

38.53 

318 

(200,900,40) 

71/395 

211.62 

884.92 

38.46 

323 

(200,1150,12) 

78/473 

200.60 

1131.26 

13.50 

2 

(350,1300,20) 

69/542 

334.06 

1290.34 

18.69 

57 

(500,1150,30) 

78/620 

490.85 

1167.41 

28.78 

152 

(500,900,40) 

77/697 

500.46 

919.38 

38.19 

182 

(350,700,50) 

76/773 

363.94 

714.32 

48.01 

222 

(200,500,50) 

71/844 

210.70 

516.42 

47.77 

217 

(250,150,50) 

104/948 

246.73 

169.28 

50.53 

167 


each Strategic level may increase up to the point at which the time taken by the Strategic 
level to reason about the next goal exceeds the minimum acceptable update rate between 
the Tactical and Strategic levels. 

To examine the impact a different computational configuration would have on the per¬ 
formance of RBM, a two workstation test was performed. In this case, the Strategic and 
Tactical levels shared the processor of a single Sun SPARCstation 1. Again, UNIX was the 
operating system and communications between the Tactical and Execution levels took 
place over Ethernet. The operating system was relied upon to provide context switching be¬ 
tween the Strategic and Tactical levels. Not surprisingly, the results of this experiment were 
essentially identical with those of the three-workstation configuration for both RBM-B and 
RBM-F. The reason for this lies in the relationship between the two levels in this implemen- 
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tation. When the Strategic level is searching for the next primitive goal, the Tactical level 
is dormant. Similarly, after the primitive goal has been issued, the Strategic level sleeps un¬ 
til it is notified by the Tactical level of goal attainment. Note that this instantiation did not 
implement any active objects. If it had, the two-workstation configuration would have suf¬ 
fered in performance because the active objects would have been blocked each time the 
Strategic level was given access to the processor. In a scenario in which the Tactical level 
includes active objects, a three-workstation configuration would allow the Tactical level 
continuous access to a processor. Of course, the objects themselves would be required to 
compete for the single processor; nevertheless, with the Strategic level searching its rule 
base, true parallel execution could then occur between all three levels of RBM. 

A trace of the primitive goals during this trial is included in Appendix A-3. This trace 
begins with the activation of the inference mechanism followed by a successful initializa¬ 
tion and the selection of the first waypoint. The mission then moves into the transit phase. 
The primitive goals supporting this phase are presented in a continuous sequence to the 
Tactical level which in turn activates the associated behaviors. During each “cycle”, the 
Strategic level checks for waypoint attainment and directs the selection of the next way- 
point, if appropriate. As can be seen, the majority of the goals supported the transit and re¬ 
turn phases of the mission. This is due to the general nature of the “search” and “task” goal. 
The expansion of the logic associated with either of these would by necessity involve ad¬ 
ditional primitive goals. 

The next experiment was designed to test the ability of the Strategic level to reason in 
the face of a subsystem failure. A battery model was included whose voltage level was a 
function of time. Again, the resulting trace is given in Appendix A-3. As expected, when 
the voltage falls below a specified threshold, the “transit” rule corresponding to the nominal 
case fails. The search them moves to the second rule, included to account for failures of this 
type. The trace indicates that the “surface” goal was encountered, and performance of this 
behavior was verified visually on the simulator. 
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F. PERFORMANCE DISCUSSION AND EVALUATION 


The importance of “visual verification” should not be taken lightly in the domain of 
autonomous vehicle control. Evaluation of a control software architecture cannot be subject 
to mathematical proof due to the complexity and diversity of the software involved. Fur¬ 
thermore, the concept of “correctness” as it relates to an autonomous vehicle’s behavior is 
a subjective one. One may speak of a vehicle’s “robust behavior in an unstructured envi¬ 
ronment” but be unable to devise proofs supporting these observations due to the lack of 
precise definitions [Ref. 62]. In lieu of this situation, evaluation must be based on actual 
performance [Ref. 192]. 

Nevertheless, some amount of verification and validation of software should occur pri¬ 
or to installation on the actual vehicle. A trace of the logic embodied in the rule set of the 
Strategic level should be examined under a variety of circumstances to insure the proper 
sequencing of primitive goals and, by extension, behaviors. Some behaviors, particularly 
those performing numeric or iterative computation, may be candidates for algorithmic anal¬ 
ysis. Individually, these can be shown to be correct from a mathematical standpoint. Taken 
collectively, this analysis should include the resulting commands to the Execution level to 
determine if goals are being effectively translated into vehicle actions. 

The ultimate test, however, is the demonstration of satisfactory performance on the tar¬ 
get vehicle. This, of coiuse, can only be determined qualitatively by the individual whose 
opinion carries the most significance—the user. 

G. SUMMARY 

This chapter presents a complete instantiation of the Rational Behavior Model using 
different programming paradigms for each level. Specifically, the Strategic level was im¬ 
plemented in Prolog, the Tactical level in Ada, and the Execution level in C. To demonstrate 
the effectiveness of this architecture, a study was performed involving a realistic simulation 
of the NPS AUV. A four-phase search and rescue mission formed the basis for the logic em¬ 
bodied in the rules of the Strategic level. The Tactical level design was patterned after the 
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watch crew of a manned submarine, partly because of the clear division of responsibility 
and chain of command. 

The experiments were performed on both two and three workstation configurations. 
The motivation for this was to demonstrate the feasibility of a heterogenous approach to the 
implementation of software architectures. Traces were taken of the execution of the Strate¬ 
gic level inference engine, and timing, positional, and heading commands were collected 
as output from the Tactical level. However, it was the observed performance of the AUV 
simulation that determined the success of the RBM architecture as a framework for the con¬ 
trol of an autonomous vehicle. 
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Vn. SUMMARY AND CONCLUSIONS 


In this dissertation, a complete, tri-level, multi-paradigm software architecture for the 
control of autonomous vehicles is defmed, instantiated, and evaluated. By definition, each 
level of the Rational Behavior Model has associated with it a particular abstraction 
mechanism which, when applied to the control problem, yields a solution that emphasizes 
software maintainability, modifiability, and a potential for reuse. At the Strategic level, 
high-level mission logic resides which provides for the deterministic sequencing of the 
underlying behaviors of the vehicle. The central Tactical level performs the computations 
and processing necessary to provide a symbolic-to-numeric interface between the two outer 
levels while implementing the behaviors capable of satisfying the goals assigned by the top 
level. Finally, the lower, Execution level contains the algorithms directly supporting the 
stability, safety, and hard real-time needs of the vehicle. These mechanisms and features 
are carried over from the design to the implementation through the use of specified 
programming paradigms, also explicit in the definition. 

This chapter lists the contributions made to computer science by this research as well 
as suggestions for possible future extensions. 

A. RESEARCH CONTRIBUTIONS 

Control of autonomous vehicles encompasses a bewildering array of problem do¬ 
mains, from classical robotics and modem control theory to automated reasoning. Research 
has tended to focus on specific aspects of the overall control problem, such as navigation, 
path replanning, fault identification and isolation, sensor integration, and modeling at the 
expense of the global issue of system control. As autonomous systems have gained in so¬ 
phistication due, in part, to breakthroughs in hardware technology, the lack of a general 
control software architecture to coordinate and organize the many diverse software sub¬ 
systems has become evident. 
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From this need has emerged the field of research dedicated to intelligent control of ro¬ 
bots, both stationary and mobile [Ref. 6]. The seminal work of Saridis [Ref. 37] argued for 
a multi-disciplinary, multi-level approach to software architectures; NASREM [Ref. 43] re¬ 
lied on a strict, top-down, hierarchical view; and Brooks [Ref. 31], partly as a philosophical 
challenge to the established robotics community, eschewed traditional approaches for a 
non-representational, behaviorally-layered architecture. 

It has become apparent that these approaches, in their purest form, cannot provide the 
necessary flexibility of performance required and expected of autonomous vehicles [Ref. 
55]. As a result, hybrid software architectures have begun to appear which exhibit both de¬ 
liberative and reflexive components. Layered architectures have been fitted with top-level 
behavior-sequencing mechanisms [Ref. 56][Ref. 193], while hierarchical systems have in¬ 
tegrated subsumptionist concepts at their lower levels [Ref. 45] [Ref. 149]. 

Despite obvious progress, important problems still remain, as many suggested hybrid 
architectures have yet to be fully implemented. In addition, the ability to readily modify ve¬ 
hicle missions has been, for the most part, inadequately addressed. The Rational Behavior 
Model, a tri-level control software architecture, has been developed with the solution to 
these particular problems in mind. 

As a way of bridging the gap from concept to implementation, RBM provides guid¬ 
ance to the autonomous vehicle system designer by explicitly specifying the programming 
paradigm and operational characteristics of each level in its definition. This was done to 
avoid the over-generalization of the solution, a common trait of existing architectures ac¬ 
counting for their less than complete instantiation. Many of these multi-level architectures, 
some recognized in the literature for a decade, remain only partially realized because of the 
lack of a perceived development strategy [Ref. 7] [Ref. 3 9] [Ref. 43]. Others have propo¬ 
nents whose research interests emphasize only one facet of the architecture [Ref. 37] [Ref. 
194]. In this dissertation, a total implementation of a multi-level control software architec¬ 
ture is presented. 
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Related to this issue is the importance RBM places on the interfaces between its three 
levels. While many architectures rely on the use of a blackboard data structure for the sup¬ 
port of inter-level communications [Ref. 43][Ref. 61][Ref. 195], RBM requires simple, 
well-defined communications paths for the transmission of commands and data. The moti¬ 
vation behind this decision was three-fold: to contribute to the isolation of responsibility at 
each level; to minimize the affect an altered state or a software change at one level has upon 
another; and to provide for the potential of integrating RBM with an existing control sys¬ 
tem. 

To facilitate the reconfiguration of the mission, it is necessary to separate mission logic 
from mission implementation. RBM accomplishes this by isolating this logic in the Strate¬ 
gic level. In other words, the portion of the architecture that specifies what the vehicle is to 
accomplish is completely divorced from the behavioral aspect of how the desired goals are 
to be attained. In addition, by excluding explicit state variables from the strategic level, the 
potential for undesired side-effects and undue complexity is avoided, further enhancing 
mission development and alteration. Several architectures have attempted similar solutions, 
but have either sacrificed simplicity for expressive power [Ref. 194] or have not provided 
a sufficient mechanism for reconfiguration [Ref. 56]. 

B. SUGGESTIONS FOR FUTURE RESEARCH 

This research discussed the relationship between the two primary approaches to soft¬ 
ware architecture construction and the form of chaining used by their respective automated 
reasoners. From a pure logic standpoint, forward and backward chaining are merely two 
possible methods to solve a given problem. However, although the end results of each ap¬ 
proach win be the same, the internal steps each takes in its path to the solution may differ 
significantly. In terms of the control of autonomous vehicles, these internal steps refer to 
the order in which behaviors and their associated side-effects are applied to the problem. 
This sequence of side-effects is often just as important to the designer and user of autono¬ 
mous systems as the confidence in ultimate mission achievement. So, whereas a forward- 
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chaining architecture may attain the desired end goal assigned to it, the level of perfor¬ 
mance displayed during execution may be unacceptable. 

The cause of this can be traced to the need for these systems to resolve conflicts asso¬ 
ciated with simultaneously activated behaviors. In many cases, conflicts are handled 
through the assignment of priorities, giving preference to the behavior considered most 
likely to move the state of the mission closer to the goal. Backward-chaining, goal-driven 
systems are characterized by their lack of conflicts with respect to behavior activations. 
This approach to reasoning, used by RBM, reflects directly the process of goal decomposi¬ 
tion and the implied ordering of goals produced. 

Despite the considerations outlined above, the majority of research in the field of au¬ 
tonomous vehicle control has been from the forward-chaining perspective. For this reason, 
RBM provides the option for a forward-chaining Strategic level. Should this option be ex¬ 
ercised, however, the requirement remains that the primitive goals passed to the Tactical 
level be in the same sequence as would be achieved through backward chaining. Prelimi¬ 
nary research into an algorithmic translation of a goal-driven solution to a forward-chaining 
implementation has resulted in the concept of the State Transition Diagram with Path Pri¬ 
orities [Ref. 140]. Development of such an algorithm is seen as a significant step towards 
merging the two approaches used in autonomous vehicles for the representation of human 
knowledge. 

At the Tactical level, further exploration and possible refinement is warranted into the 
characteristics of the object hierarchy. Although ideally suited for a concurrent executing 
environment, the implementation detailed in this dissertation did not utilize the facility of 
multitasking provided by the Ada programming language. At issue here are performance 
enhancements and the potential impact concurrent programming has on software complex¬ 
ity and interaction. From the experimental results of Chapter VI, it was found that the per¬ 
formance of the simulation was virtually identical regardless of whether execution took 
place on two or three processors. Accounting for this is the minimal impact of inter-proces¬ 
sor communications and the sequential relationship between the two levels. The conclusion 
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can then be drawn that for RBM implementations consisting of only static objects at the 
Tactical level, one processor is sufficient to host both the Strategic and Tactical levels. This 
would not be true for instantiations of RBM involving true parallelism at the Tactical level. 

There exists a need to join this work to that done with pre-mission operator interfaces 
[Ref, 189], These systems are designed to automatic£illy generate the path(s) to be taken by 
the vehicle in the completion of its mission. These paths are typically in the form of lists of 
waypoints. This process is seen as an adjunct to the task of mission decomposition for the 
determination of primitive goals. In the researched reported in this dissertation, path plan¬ 
ning and mission definition were handled in separate steps. 

Another potential area of research relating to the expression of missions within the 
RBM framework is the development of language translators for the Strategic level. In the 
instantiations described in this work, Prolog and CLIPS were selected as examples of rule- 
based languages capable of effectively representing compiled human knowledge. Further¬ 
more, these languages are made even more attractive by their inclusion of an inference 
mechanism responsible for the control of rule activation and firing. Once the mission has 
been defined to a sufficient degree, it is conceivable, and may even be desirable, to employ 
a language such as Lisp or Ada as the implementation language at the top level. For exam¬ 
ple, a complete, executable mission program written in Prolog may be available while cir¬ 
cumstances dictate that some other language be used. Manual translations of this type indi¬ 
cate that this process may lend itself to automation [Ref. 196], Of course, when generating 
non-rule-based language systems, the translator must bear the responsibility of representing 
knowledge in an effective way while properly emulating the relationship that exists be¬ 
tween rule base and inference engine. 

As presently defined, the Strategic level, once encoded, is immutable. This view de¬ 
rives from the paramount importance of predictability in vehicles designed for military ap¬ 
plications. However, the applicability to RBM of machine learning resulting in modified 
rule sets better able to cope with uncertain environments may prove to be an important ex¬ 
tension. In related research, an approach to the testing and evaluation of autonomous vehi- 
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cle controllcT performance using genetic algorithms has been recently demonstrated [Ref. 
197]. These techniques are seen as a way to measure the robustness of an intelligent con¬ 
troller by subjecting it to a number of adaptively-chosen fault scenarios. An investigation 
into the integration of this research with the implementation of RBM is certainly warranted. 
In the final analysis, the success of a software architecture is measured in terms of how 
well it provides structure and ease of interaction to the many software components while 
preventing undesirable interference or interaction between them. Since a feel for the “math- 
ematicai” correctness of a software architecture is not feasible, the system must be imple¬ 
mented on a real vehicle and its resulting behavior observed before full validation can be 
claimed. Unfortunately, the time schedules of the author and the rebuild schedule of the 
NFS AUV did not coincide sufficiently to allow this. An experimental validation on a de¬ 
tailed simulation of the vehicle is not without value, however, and much doctoral-level re¬ 
search into architectural approaches to autonomous vehicle control have relied on it [Ref. 
60][Ref. 62][Ref. 198]. Nevertheless, the results demonstrated by the actual NFS AUV run¬ 
ning the Florida search-and-rescue mission under the overall control of RBM will provide 
an important epilog to this research. 
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APPENDIX A. STRATEGIC LEVEL PROGRAM LISTINGS 


L PROLOG IMPLEMENTATION (RBM-B) 


/* Strategic Level for the RBM AUV Mission Controller/Coordinator 
by Byrnes, Kwak, Healey, Marco for use in the Florida Mission 


Version: 2.5 Dec 15, 1992*/ 

j* -MISSION SPECIFICATION FOR SEARCH AND RESCUE-*/ 

compUe(library(not)), /* A Quintus Prolog library providing “not” predicate */ 

compile(floridaforeign). /* This file contains the foreign language interface */ 

initializeready_vehicle_for_launch_p(ANSl), ANSI == 1, 
select_first_waypoint( ANS 2). 
initializealeit_user(ANS), fail, 

mission in_transit_p(ANSl), ANSI == 1, transit, !, transit_done_p(ANS2), ANS2 = 1, 
fail. 

mission in_search_p(ANSl), ANSI == 1, search,!, search_done_p(ANS2),ANS2 == 1, 
fail. 

mission in_task:_p(ANSl), ANSI == 1, task,!, task_done_p(ANS2), ANS2 == 1, fail, 
mission in_retum_p(ANSl), ANSI == 1, return,!, retum_done_p(ANS2), ANS2 == 1, 
wait_foT_recovery(ANS3). 

transitwaypoint_control. 

transitsurface(ANS 1), wait_for_recovery(ANS2). 

search do_search_pattem(ANS), ANS — 1. 
searchsurface(ANSl), wait_for_recovery(ANS2). 
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taskhoming(ANSl), ANSI = 1, clrop_package(ANS2), ANS2 == 1, 

get_gps_fix(ANS3), ANS3 = 1, get_next_waypoint(ANS4), ANS4 
task surface(ANSl), wait_for_recovery(ANS2). 

return waypoint_control. 

return surface(ANSl), wait_for_recovery(ANS2). 


/* 


NFS AUV DOCTRINE -.*/ 


execute_auv_mission initialize, repeat, mission. 

waypoint_controlnot(critical_system_prob), get_waypoint_status, plan, 
send_setpoints_and_modes(ANS). 

get_waypoint_status gps_check, reach_waypoint_p(ANSl), ANSI == 1, 

get_next_waypomt( ANS 2). 

get_waypoint_status. 

gps_checkgps_needed_p(ANSl), ANSI == 1, get_^s_fix(ANSl). 
gps_check. 

plan reduced_capacity_system_prob, global_replan. 
plannear_uncharted_obstacle, local_replan. 
plan. 

near_uncharted_obstacle unknown_obstacle_p(ANSl), ANSI == 1, 

log_new_obstacle(ANS2). 

local_replan loiter(ANSl), start_local_replanner(ANS2). 
global_replanloiter(ANSl), start_global_replanner(ANS2). 
critical_system_prob power_gone_p(ANS), ANS == 1. 
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critical_system_prob computer_system_inop_p(ANS), ANS == 1. 
critical_system_prob propulsion_systeni_p(ANS), ANS = 1. 
critical_system_prob steering_system_mop_p(ANS), ANS == 1. 

reduced_capacity_system_prob diving system p(ANS), ANS == 1. 
reduced_capacity_system_prob bouyancy_system_p(ANS), ANS == 1. 
reduced_capacity_system_prob thruster_system_p(ANS)» ANS == 1. 
reduced_capacity_system_prob leak_test_p(ANS), ANS == 1. 
reduced_capacity_system_prob payload_prob_p(ANS), ANS == 1. 
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2. CLIPS IMPLEMENTATION (RBM-F) 


.^ ^ ^ ^ 9k ^ ^ ^ 3k ^ He ^ ^ ^ ^ 3je 3)C ^ )ie jfe sje >fc ){C % ^ ^ % ))C :fc ije 9|c ^ % :|c}fe pH ^ ^ ^ ^3}$ }fc % ^ % He % ^ ^ ^ ^ ^ ^ ^ 

* Title : Strategic Level for the NPS AUVII 

,* Name : strlev4.0 

;* Version : 4.0 

,* Author : Thomas Scholz 

* Date : 22 February 1993 

* Revised : 23 February 1993 - First good run at 11:45am 

;* System : Sun UNIX 

* Compiler : Clips 5.1 

* Description : This program is the strategic level of the NPS AUV II, 

,* top level of the Rational Behavioral Model design 

* Remarks : Don’t make any changes to this program! 

* It runs fine on the NPS AUV Simulator on IRIS! 

* 

«/. \t- 1^ 4^* */i» ■itr fct.. 4 f. fcip. 4#- -1 - . I. tfft ^1* 4^ 4|. fcip. -t- 4^ Ua 4 I* *1^ 

■ ^ ^ ^ ^ “n •T* ♦ ^ ^ ^ ^ •t* ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ *1' 'i' 'i' «j« <i» 'i' 


.****!(c***i)c*****<!****j(cj,jpg ^uv - RBM Mission ControUer/Coordinator*********** 


.3kPk9kH:HeHePk3kHEHi3k%H:3k3kikHEPk3k9k3kHEPkPkPk9k3k»kHi3k3kH:3k 'J'g|^p2£lt0S PkHsHeskJkPkHepk+HcH^PkJkHeJkHcHtHsNcHeHsJkHeJkHcskHsHcHt 


(deftemplate execute-auv-mission 
(field state 

(type SYMBOL) 

(allowed-symbols initialize mission done inactive) 

(default inactive))) 


(deftemplate or-initialize 
(field state 

(type SYMBOL) 

(allowed-S3rmbols or_initialize_l 

or_initialize_2 
failed done inactive) 
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(default inactive))) 


(deftemplate initialize 
(field state 

(type SYMBOL) 

(allowed-symbols start 

select_first_waypoint 

alert_user 

failed done inactive) 

(default inactive))) 


(deftemplate or-mission 
(field state 

(type SYMBOL) 

(allowed-symbols or_mission_l 

or_mission_2 
or_mission_3 
or_mission_4 
done inactive) 

(default inactive))) 


(deftemplate mission 
(field state 

(type SYMBOL) 

(allowed-symbols start 

transit in_transit_p transit_done_p 
search in_search_p search_done_p 
task in_task_p task_done_p 
return in_return_p return_done_p 
done inactive) 

(default inactive))) 

(deftemplate transit 
(field state 

(type SYMBOL) 

(allowed-symbols start 

waypoint_control 

surface 

done inactive) 
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(default inactive))) 


(deftemplate or-transit 
(field state 

(type SYMBOL) 

(allowed-symbols or_transit_l 

or_transit_2 
done inactive) 

(default inactive))) 


(deftemplate search 
(field state 

(type SYMBOL) 

(allowed-symbols start 

do_search_pattern 

surface 

done inactive) 

(default inactive))) 


(deftemplate or-search 
(field state 

(type SYMBOL) 

(allowed-symbols or_search_l 

or_search_2 
done inactive) 

(default inactive))) 


(deftemplate task 
(field state 

(type SYMBOL) 

(allowed-symbols start 

homing drop_package get_gps_fix 
get_next_waypoint surface 
done inactive) 

(default inactive))) 


(deftemplate or-task 
(field state 
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(type SYMBOL) 
(allowed-symbols 


(default inactive))) 

(deftemplate return 
(field state 

(type SYMBOL) 
(allowed-symbols 


(default inactive))) 

(deftemplate or-return 
(field state 

(type SYMBOL) 
(allowed-symbols 


(default inactive))) 


(deftemplate waypoint-control 
(field state 

(type SYMBOL) 
(allowed-symbols 


(default inactive))) 


(deftemplate get-waypoint-status 
(field state 

(type SYMBOL) 
(allowed-symbols 


or_task_l 
or_task_2 
done inactive) 


start 

waypoint_control 

surface 

done inactive) 


or_return_l 
or_retum_2 
done inactive) 


start 

crit_system_prob 
get_waypoint_status 
plan send_setpoints_and_modes 
done inactive) 


start 

gps_check 

reach_waypoint 







get_next_wayp oint 
done inactive) 

(default inactive))) 

(deftemplate or-get-waypoint-status 
(field state 

(type SYMBOL) 

(allowed-symbols or_get_waypoint_status_l 

or_get_waypoint_status_2 
done inactive) 

(default inactive))) 


(deftemplate gps-check 
(field state 

(type SYMBOL) 

(allowed-symbols start 

gps_needed 
get_gps_fix 
done inactive) 

(default inactive))) 


(deftemplate or-gps-check 
(field state 

(type SYMBOL) 

(allowed-symbols or_gps_check_l 

or_gps__check_2 
done inactive) 

(default inactive))) 


(deftemplate plan 
(field state 

(type SYMBOL) 

(allowed-symbols start 

red_cap_system_prob 

near_uncharted_obstacle 

global_replan 

local_replan 

done inactive) 

(default inactive))) 
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(deftemplate or-plan 
(field state 

(type SYMBOL) 

(allowed-symbols or_plan_l 

or_pian_2 
or_plan_3 
done inactive) 

(default inactive))) 


(deftemplate near-uncharted-obstacle 
(field state 

(type SYMBOL) 

(allowed-symbols start 

unknown_obstacle_p 
log_new_obstacle 
done inactive) 

(default inactive))) 


(deftemplate global-replan 
(field state 

(type SYMBOL) 

(allowed-symbols start 

loiter 

start_gIobal_replanner 
done inactive) 

(default inactive))) 


(deftemplate local-replan 
(field state 

(type SYMBOL) 

(allowed-symbols start 

loiter 

start_local_replanner 
done inactive) 

(default inactive))) 


(deftemplate crit-system-prob 
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(field state 

(type SYMBOL) 

(allowed-symbols start 

power_gone_p 
c omputer_sy stem_inop_p 
propulsion_system_p 
steering_system_inop_p 
done inactive) 

(default inactive))) 


(deftemplate or-crit-system-prob 
(field state 

(type SYMBOL) 

(allowed-symbols or_ciit_system_prob_l 

or_crit_system_prob_2 
or_crit_system_prob_3 
or_crit_sy stem_pro b_4 
done inactive) 

(default inactive))) 


(deftemplate red-cap-system-prob 
(field state 

(type SYMBOL) 

(allowed-symbols start 

diving_system_p 

bouyancy_system_p 

thruster_system_p 

leak_test_p 

payload_prob_p 

done inactive) 

(default inactive))) 


(deftemplate or-red-cap-system-prob 
(field state 

(type SYMBOL) 

(allowed- symbols or_red_cap_sy stem_prob_ 1 

or_red_cap_system_prob_2 

or_red_cap_system_prob_3 

or_red_cap_system_prob_4 

or_red_cap_system_prob_5 






(default inactive))) 


done inactive) 


.J(:!i!3(:***J|c*******S|t******;|:ij!*4!***;j.*3(t:(s:j.*^3j5 ****!(!**!(!**!|t***!k**********s|csic*** 


(defrule execute-auv-mission-lO-s 
?x <- (start) 

=> 

(retract ?x) 

(assert (execute-auv-mission (state initialize)))) 


(defrule execute-auv-mission-10-e 

?x <- (execute-auv-mission (state done)) 

=> 

(retract ?x) 

(reset) 

(assert (execute-auv-mission (state mission)))) 


(defrule execute-auv-mission-ll-s 

(execute-auv-mission (state initialize)) 

=> 

(assert (initialize (state start)))) 


(defrule execute-auv-mission-11-e 

?x <- (execute-auv-mission (state initialize)) 
?y <- (initialize (state done)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (execute-auv-mission (state mission)))) 


(defrule execute-auv-mission-12-s 

(execute-auv-mission (state mission)) 

=> 

(assert (mission (state start)))) 
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(defrule execute-auv-mission-12-e 

?x <- (execute-auv-mission (state mission)) 
?y <- (mission (state done)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (execute-auv-mission (state done)))) 


(defrule initialize-lO-s 

(declare (salience 10)) 

?x <- (initialize (state start)) 

=> 

(retract ?x) 

(assert (or-initialize (state or_initiali 2 e_l))) 
(assert (initialize (state select_first_waypoint)))) 


(defrule initialize-10-e 

(declare (salience -10000)) 

?x <- (or-initiaiize (state or_initialize_l)) 

=> 

(retract ?x) 

(assert (or-initialize (state or_initiali 2 e_ 2 )))) 


(defrule initialize-11 

(or-initialize (state or_initialize_l)) 

(initialize (state select_first_waypoint)) 

(test (= (ready_vehicle_for_launch) 1)) 

=> 

(select_first_waypoint) 

(assert (initialize (state done))) 

(printout t “* * * auv execution initialized * * *” crlf crlf)) 


(defrule initialize-20-s 

(or-initiaUze (state or_initialize_2)) 

=> 

(assert (initialize (state alert_user)))) 


(defrule initialize-20-e 
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?x <- (initialize (state alert_user)) 

(retract ?x) 

(alert_user) 

(printout t “*** initialize failed ***” crlf crlf) 
(assert (initialize (state failed)))) 


(defrule mission-10-s 

(declare (salience 30)) 

?x <- (mission (state start)) 

=> 

(retract ?x) 

(assert (or-mission (state or__mission_l))) 
(assert (mission (state transit)))) 


(defrule mission-10-e 

(declare (salience -1000)) 

?x <- (or-mission (state or_mission_l)) 

=> 

(retract ?x) 

(assert (or-mission (state or_mission_2)))) 


(defrule mission-11-s 

(or-mission (state or_mission_l)) 
(mission (state transit)) 

(test (= (in_transit_p) 1)) 

=> 

(assert (transit (state start)))) 


(defrule mission-11-e 

(or-mission (state or_mission_l)) 

?x <- (mission (state transit)) 

?y <- (transit (state done)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (mission (state transit_done_p)))) 
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(defirule mission-12 

(or-mission (state or_mission_l)) 

?x <- (mission (state transit_done_p)) 
(test (= (transit_done_p) 1)) 

=> 

) 


(defrule mission-20-s 

(declare (salience 20)) 
(or-mission (state or_mission_2)) 

=> 

(assert (mission (state search)))) 


(defrule mission-20-e 

(declare (salience -1000)) 

?x <- (or-mission (state or_mission„2)) 

=> 

(retract ?x) 

(assert (or-mission (state or_mission_3)))) 


(defrule mission-21-s 

(or-mission (state or_mission_2)) 
(mission (state search)) 

(test (= (in_search_p) 1)) 

=> 

(assert (search (state start)))) 


(defrule mission-21-e 

(or-mission (state or_mission_2)) 

?x <- (mission (state search)) 

?y <- (search (state done)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (mission (state search_done_p)))) 


(defrule mission-22 

(or-mission (state or_mission_2)) 
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?x <- (mission (state search_done_p)) 
(test (= (search_done_p) 1)) 

) 


=> 


(defrule mission-30-s 

(declare (salience 10)) 
(or-mission (state or_mission_3)) 

=> 

(assert (mission (state task)))) 


(defrule mission-30-e 

(declare (salience -1000)) 

?x <- (or-mission (state or_mission„3)) 

=> 

(retract ?x) 

(assert (or-mission (state or_mission_4)))) 


(defrule mission-31-s 

(or-mission (state or_mission_3)) 
(mission (state task)) 

(test (= (in_task_p) 1)) 

=> 

(assert (task (state start)))) 


(defrule mission-31-e 

(or-mission (state or_niission_3)) 

?x <- (mission (state task)) 

?y <- (task (state done)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (mission (state task_done_p)))) 


(defrule mission-32 

(or-mission (state or_mission_3)) 
?x <- (mission (state task_done_p)) 
(test (= (task_done_p) 1)) 
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) 


=> 


(defrule mission-40-s 

(declare (salience 0)) 

(or-mission (state or_mission_4)) 

=> 

(assert (mission (state return)))) 


(de&ule mission-40-e 

(declare (salience -1000)) 

?x <- (or-mission (state or_mission_4)) 

=> 

(retract ?x) 

(assert (mission (state done)))) 


(defrule mission-41-s 

(or-mission (state or_mission_4)) 
(mission (state return)) 

(test (= (in_return_p) 1)) 

=> 

(assert (return (state start)))) 


(defrule mission-41-e 

(or-mission (state or_mission_4)) 

?x <- (mission (state return)) 

?y <- (return (state done)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (mission (state retum_done_p)))) 


(defrule mission42 

(or-mission (state or_mission_4)) 

?x <- (mission (state retum_done_p)) 
(test (= (retum_done_p) 1)) 

=> 

(wait_for_recovery) 
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(retract ?x)) 


(defrule transit-lO-s 

(declare (salience 10)) 

?x <- (transit (state start)) 

=> 

(retract ?x) 

(assert (or-transit (state or_transit_l)))) 


(defrule transit-lO-el 

(declare (salience 9)) 

(transit (state done)) 

?x <- (or-transit (state or_transit_l)) 

=> 

(retract ?x)) 


(defrule transit-10-e 

(declare (salience -100)) 

?x <- (or-transit (state or_transit_l)) 

=> 

(retract ?x) 

(assert (or-transit (state or_transit_2)))) 


(defrule transit-11-s 

(or-transit (state or_transit_l)) 


(assert (transit (state waypoint_control))) 
(assert (waypoint-control (state start)))) 


(defrule transit-11-end 

(or-transit (state or_transit_l)) 

?y <- (transit (state waypoint_control)) 
?z <- (waypoint-control (state done)) 

=> 

(retract ?y) 

(retract ?z) 

(assert (transit (state done)))) 
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(defrule transit-21-s 

(or-transit (state or_transit_2)) 

=> 

(assert (transit (state surface)))) 


(defrule transit-21-end 

?x <- (or-transit (state or_transit_2)) 
?y <- (transit (state surface)) 

=> 

(surface) 

(retract ?x) 

(retract ?y) 

(assert (transit (state done)))) 


(defrule search-10-s 

(declare (salience 10)) 

?x <- (search (state start)) 

=> 

(retract ?x) 

(assert (or-search (state or_search_l)))) 


(defrule search- 10-el 
(declare (salience 9)) 

(search (state done)) 

?x <- (or-search (state or_search_l)) 

=> 

(retract ?x)) 


(defrule search-10-e 

(declare (salience -100)) 

?x <- (or-search (state or_search_l)) 

=> 

(retract ?x) 

(assert (or-search (state or_search_2)))) 


(defrule search-11-s 

(or-search (state or_search_l)) 
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(assert (search (state do_search_pattem)))) 


=> 


(defrule search* 11 -end 

(or-search (state or_search_l)) 

?y <- (search (state do_search_pattem)) 
(test (= (do_search_pattern) 1)) 

=> 

(retract ?y) 

(assert (search (state done)))) 


(defrule search-21-s 

(or-search (state or_search_2)) 

=> 

(assert (search (state surface)))) 


(defrule search-21-end 

?x <- (or-search (state or_search_2)) 
?y <- (search (state surface)) 

=> 

(surface) 

(retract ?x) 

(retract ?y) 

(assert (search (state done)))) 


(defrule task-lO-s 

(declare (salience 10)) 

?x <- (task (state start)) 

=> 

(retract ?x) 

(assert (or-task (state or_task_l)))) 


(defrule task-10-el 

(declare (salience 9)) 

(task (state done)) 

?x <- (or-task (state or_task_l)) 

=> 

(retract ?x)) 
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(defrule task-lO-e 

(declare (salience -100)) 

?x <- (or-task (state or_task_l)) 

=> 

(retract ?x) 

(assert (or-task (state or_task_2)))) 


(defrule task-11-s 

(or-task (state or_task_l)) 

=> 

(assert (task (state homing)))) 


(defrule task-11-e 

(or-task (state or_task_l)) 

?x <- (task (state homing)) 

(test (= (homing) 1)) 

=> 

(retract ?x) 

(assert (task (state drop_package)))) 


(defrule task-12 

(or-task (state or_task_l)) 

?x <- (task (state drop_package)) 
(test (= (drop_package) 1)) 

=> 

(retract ?x) 

(assert (task (state get_gps_fix)))) 


(defrule task-13 

(or-task (state or_task_l)) 

?x <- (task (state get_gps_flx)) 

(test (= (get_gps_fix) 1)) 

=> 

(retract ?x) 

(assert (task (state get^next^waypoint)))) 
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(defrule task-14-end 

(or-task (state or_task_l)) 

?y <- (task (state get_next_waypoint)) 
(test (= (get_next_waypoint) 1)) 

=> 

(retract ?y) 

(assert (task (state done)))) 


(defrule task-21-s 

(or-task (state or_task_2)) 

=> 

(assert (task (state surface)))) 


(defrule task-21-end 

?x <- (or-task (state or_task_2)) 

?y <- (task (state surface)) 

=> 

(surface) 

(retract ?x) 

(retract ?y) 

(assert (task (state done))) 

(printout t “*** starting task failed ***” crlf) 

(printout t crlf “-h-i- auv is surfacing [due to problems] -H-+” crlf) 
(printout t “+-t+ [and] mission execution terminated -i-n-” crlf crlf)) 


(defrule return-10-s 

(declare (salience 10)) 

?x <- (return (state start)) 

=> 

(retract ?x) 

(assert (or-retum (state or_retum_l)))) 


(defrule return-10-el 

(declare (salience 9)) 

(return (state done)) 

?x <- (or-retum (state or_retum_l)) 

=> 

(retract ?x)) 
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(defrule return-10-e 

(declare (salience -100)) 

?x <- (or-retum (state or_return_l)) 

=> 

(retract ?x) 

(assert (or-retum (state or_return_2)))) 


(defrule return-11-s 

(or-retum (state or_Teturn_l)) 

=> 


(assert (return (state waypoint_control))) 
(assert (waypoint-control (state start)))) 


(defrule return-11-end 

(or-retum (state or_retum_l)) 

?y <- (return (state waypoint_control)) 
?z <- (waypoint-control (state done)) 

=> 

(retract ?y) 

(retract ?z) 

(assert (return (state done)))) 


(defrule retum-21-s 

(or-retum (state or_return_2)) 

=> 

(assert (return (state surface)))) 


(definle retum-21-end 

?x <- (or-retum (state or_retum_2)) 
?y <- (return (state surface)) 

=> 

(surface) 

(retract ?x) 

(retract ?y) 

(assert (return (state done)))) 


(defrule waypoint-control-10-s 
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?x <- (waypoint-control (state start)) 


(retract ?x) 

(assert (waypoint-control (state crit_system_prob)))) 


(defrule waypoint-control-11-s 

(waypoint-control (state crit_system_prob)) 

=> 

(assert (crit-system-prob (state start)))) 


(defrule waypoint-control-11 -e 

?x <- (waypoint-control (state crit_system_prob)) 

(not (crit-system-prob (state done))) 

=> 

(retract ?x) 

(assert (waypoint-control (state get_waypoint_status)))) 


(defrule waypoint-control-12-s 

(waypoint-control (state get_waypoint_status)) 

=> 

(assert (get-waypoint-status (state start)))) 


(defrule waypoint-control-12-e 

?x <- (waypoint-control (state get_waypoint_status)) 
?y <- (get-waypoint-status (state done)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (waypoint-control (state plan)))) 


(defrule waypoint-control-13-s 

(waypoint-control (state plan)) 

=> 

(assert (plan (state start)))) 


(defrule waypoint-control-13-e 

?x <- (waypoint-control (state plan)) 
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?y <- (plan (state done)) 


(retract ?x) 

(retract ?y) 

(assert (waypoint-control (state send_setpoints_and_modes)))) 


(defrule waypoint-control-14-end 

?x <- (waypoint-control (state send_setpoints_and_modes)) 

=> 

(send_setpoints_and_modes) 

(retract ?x) 

(assert (waypoint-control (state done)))) 


(defrule get-waypoint-status-10-s 
(declare (salience 10)) 

?x <- (get-waypoint-status (state start)) 

=> 

(retract ?x) 

(assert (or-get-waypoint-status (state or_get_waypoint_status_l)))) 


(defrule get-waypoint-status-10-el 
(declare (salience -9)) 

(get-waypoint-status (state done)) 

?x <- (or-get-waypoint-status (state or_get_waypoint_status_l)) 

=> 

(retract ?x)) 


(defrule get-waypoint-status-10-e 
(declare (salience -10)) 

?x <- (or-get-waypoint-status (state or_get_wa)^oint_status_l)) 

=> 

(retract ?x) 

(assert (or-get-waypoint-status (state or_get_waypoint_status_2)))) 


(defrule get-waypoint-status-11-s 

(or-get-waypoint-status (state or_get_waypoint_status_l)) 

=> 

(assert (get-waypoint-status (state gps_check))) 
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(assert (gps-check (state start)))) 


(defrule get-wa3T3oint-status-l 1-e 

(or-get-waypoint-status (state or_get_waypoint_status_l)) 
?x <- (get-waypoint-status (state gps_check)) 

?y <- (gps-check (state done)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (get-waypoint-status (state reach_waypoint)))) 


(defiiile get-waypoint-status-12-end 

(or-get-waypoint-status (state or_get_waypoint_status_l)) 
?y <- (get-waypoint-status (state reach_waypoint)) 

(test (= (reach_waypoint) 1)) 

=> 

(get_next_waypoint) 

(retract ?y) 

(assert (get-waypoint-status (state done)))) 


(defrule get-waypoint-status-21-end 

?x <- (or-get-waypoint-status (state or_get_waypoint_status_2)) 


(retract ?x) 

(assert (get-waypoint-status (state done)))) 


(defrule gps-check- 10-s 

(declare (salience 10)) 

?x <- (gps-check (state start)) 

=> 

(retract ?x) 

(assert (or-gps-check (state or_gps_check_l)))) 


(defrule gps-check-10-el 

(declare (salience 9)) 

(gps-check (state done)) 

?x <- (or-gps-check (state or_gps_check_l)) 
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(retract ?x)) 


(defrule gps-check-lO-e 

(declare (salience -10)) 

?x <- (or-gps-check (state or_gps_check_l)) 

=> 

(retract ?x) 

(assert (or-gps-check (state or_gps_check_2)))) 


(defrule gps-check-ll-s 

(or-gps-check (state or_gps_check_l)) 

(assert (gps-check (state gps_needed)))) 


(defrule gps-check-11-end 

(or-gps-check (state or_gps_check_l)) 
?y <- (gps-check (state gps_needed)) 
(test (= (gps_needed) 1)) 

=> 

(get_gps_fix) 

(retract ?y) 

(assert (gps-check (state done)))) 


(defrule gps-check-21-end 

?x <- (or-gps-check (state or_gps_check_2)) 

=> 


(retract ?x) 

(assert (gps-check (state done)))) 


(defiTile plan-lO-s 

(declare (salience 10)) 

?x <- (plan (state start)) 

=> 

(retract ?x) 

(assert (or-plan (state or_plan_l)))) 


(defrule plan-20-s 
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(declare (salience -10)) 

?x <- (or-plan (state or_plan_l)) 

(retract ?x) 

(assert (or-plan (state or_plan_2)))) 


(defhile plan-30-s 

(declare (salience -20)) 

?x <- (or-plan (state or_plan_2)) 

=> 

(retract ?x) 

(assert (or-plan (state or_plan_3)))) 


(defrule plan-ll-s 

(or-plan (state or_plan_l)) 

=> 


(assert (plan (state red_cap_system_prob))) 
(assert (red-cap-system-prob (state start)))) 


(defrule plan-11-e 

(or-plan (state or_plan_l)) 

?x <- (plan (state red_cap_system_prob)) 
?y <- (red-cap-system-prob (state done)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (plan (state global_replan))) 
(assert (global-replan (state start)))) 


(defrule plan-12-s 

(or-plan (state or_plan_l)) 

?x <- (plan (state global_replan)) 
?y <- (global-replan (state done)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (plan (state done)))) 
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(defrule plan-21-s 

(or-plan (state or_plan_2)) 

=> 


(assert (plan (state near_uncharted_obstacle))) 
(assert (near-uncharted-obstacle (state start)))) 


(defrule plan-21-e 

(or-plan (state or_plan_2)) 

?x <- (plan (state neai_uncharted_obstacle)) 
?y <- (near-uncharted-obstacle (state done)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (plan (state local_replan))) 

(assert (local-replan (state start)))) 


(defirule plan-22-end 

?x <- (or-plan (state or_plan_2)) 
?y <- (plan (state local_replan)) 
?z <- (local-replan (state done)) 

=> 

(retract ?x) 

(retract ?y) 

(retract ?z) 

(assert (plan (state done)))) 


(defrule plan-31-end 

?x <- (or-plan (state or_plan_3)) 

=> 


(retract ?x) 

(assert (plan (state done)))) 


(defrule near-uncharted-obstacle-10-s 

?x <- (near-uncharted-obstacle (state start)) 

=> 

(retract ?x) 

(assert (near-uncharted-obstacle (state unknown_obstacle_p)))) 
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(defrule near-uncharted-obstacle-11-s 

?x <- (near-uncharted-obstacle (state unknown_obstacle_p)) 
(test (= (unknown_obstacle_p) 1)) 

=> 

(retract ?x) 

(assert (near-uncharted-obstacle (state Iog_new_obstacle)))) 


(defrule near-uncharted-obstacle- 12-end 

?x <- (near-uncharted-obstacie (state log_new_obstacle)) 

=> 

(log_new_obstacle) 

(assert (near-uncharted-obstacle (state done)))) 


(defrule local-replan-10-s 

?x <- (local-replan (state start)) 

=> 

(retract ?x) 

(assert (local-replan (state loiter)))) 


(defrule local-replan-11-s 

?x <- (local-replan (state loiter)) 

=> 

(loiter) 

(retract ?x) 

(assert (local-replan (state start_Iocal_replanner)))) 


(defrule local-replan-12-end 

?x <- (local-replan (state start_local_replanner)) 

=> 


(start_local_replanner) 

(retract ?x) 

(assert (local-replan (state done)))) 


(defrule global-replan-10-s 

?x <- (global-replan (state start)) 

=> 

(retract ?x) 

(assert (global-replan (state loiter)))) 
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(defrule global-replan-11-s 

?x <- (global-replan (state loiter)) 

=> 

(loiter) 

(retract ?x) 

(assert (global-replan (state start_giobal_replanner)))) 


(defrule global-replan-12-end 

?x <- (global-replan (state start_global_replanner)) 

=> 


(start_global_replanner) 

(retract ?x) 

(assert (global-replan (state done)))) 


(defrule crit-system-prob-lO-s 
(declare (salience 10)) 

?x <- (crit-system-prob (state start)) 

=> 

(retract ?x) 

(assert (or-crit-system-prob (state or_crit_system_prob_l)))) 


(defrule crit-system-prob-10-end 
(declare (salience 1)) 

?x <- (or-crit-system-prob (state or_crit_system_prob_4)) 
?y <- (crit-system-prob (state steering_system„inop_p)) 

=> 

(retract ?x) 

(retract ?y)) 


(defirule crit-system-prob-20-s 
(declare (salience 9)) 

?x <- (or-crit-system-prob (state or_crit_system_prob_l)) 

?y <- (crit-system-prob (state power_gone_p)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (or-crit-system-prob (state or_crit_system_prob_2)))) 
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(defrule crit-system-prob-30-s 
(declare (salience 8)) 

?x <- (or-crit-system-prob (state or_crit_systeni_prob_2)) 

?y <- (crit-system-prob (state computer_systemJnop_p)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (or-crit-system-prob (state or_crit_system_prob_3)))) 


(defrule crit-system-prob-40-s 
(declare (salience 7)) 

?x <- (or-crit-system-prob (state or_crit_system_prob_3)) 

?y <- (crit-system-prob (state propulsion_system_p)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (or-crit-system-prob (state or_crit_system_prob_4)))) 


(defrule crit-system-prob-11-s 

(or-crit-system-prob (state or_crit_system__prob_l)) 

=> 

(assert (crit-system-prob (state power_gone_p)))) 


(defrule crit-system-prob-11-end 
(declare (salience 10)) 

?x <- (or-crit-system-prob (state or_crit_system_prob_l)) 
?y <- (crit-system-prob (state power_gone_p)) 

(test (= (power_gone_p) 1)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (crit-system-prob (state done)))) 


(defrule crit-system-prob-21-s 

(or-crit-system-prob (state or_crit_system_prob_2)) 

=> 

(assert (crit-system-prob (state computer_system_inop_p)))) 
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(defrule crit-system-prob-21-end 
(declare (salience 9)) 

?x <- (or-crit-system-prob (state or_crit_systein_prob_2)) 
?y <- (crit-system-prob (state computer_system_inop_p)) 
(test (= (computer_system_inop_p) 1)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (crit-system-prob (state done)))) 


(defrule crit-system-prob-31-s 

(or-crit-system-prob (state or_crit_system_prob_3)) 

=> 

(assert (crit-system-prob (state propulsion_system_p)))) 


(defrule crit-system-prob-31-end 
(declare (salience 8)) 

?x <- (or-crit-system-prob (state or_crit_system_prob_3)) 
?y <- (crit-system-prob (state propulsion_system_p)) 

(test (= (propulsion_system_p) 1)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (crit-system-prob (state done)))) 


(defrule crit-system-prob-41-s 

(or-crit-system-prob (state or__cnt_system_prob_4)) 

=> 

(assert (crit-system-prob (state steering_system_inop_p)))) 


(defrule crit-system-pro b-41-end 
(declare (salience 7)) 

?x <- (or-crit-system-prob (state or_crit_system_prob_4)) 
?y <- (crit-system-prob (state steering_system_inop_p)) 
(test (= (steering_system_inop_p) 1)) 

=> 

(retract ?x) 
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(retract ?y) 

(assert (crit-system-prob (state done)))) 


(defrule red-cap-sy stem-pro b-10-s 
(declare (salience 10)) 

?x <- (red-cap-system-prob (state start)) 

=> 

(retract ?x) 

(assert (or-red-cap-system-prob (state or_red_cap_system_prob_l)))) 


(defrule red-cap-system-prob-10-end 

?x <- (or-red-cap-system-prob (state or_red_cap_system_piob_5)) 
?y <- (red-cap-system-prob (state payload_prob_p)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (red-cap-system-prob (state done))) 


(defrule red-cap-system-prob-20-s 
(declare (salience 9)) 

?x <- (or-red-cap-system-prob (state or_red_cap_system_prob_l)) 

?y <- (red-cap-system-prob (state diving_system_p)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (or-red-cap-system-prob (state or j'ed_cap_system_prob_2)))) 


(defraile red-cap-system-prob-30-s 
(declare (salience 8)) 

?x <- (or-red-cap-system-prob (state or_red_cap_system_prob_2)) 

?y <- (red-cap-system-prob (state bouyancy_system_p)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (or-red-cap-system-prob (state or_red_cap_system_prob_3)))) 


(defrule red-cap-system-prob-40-s 
(declare (salience 7)) 


182 





?x <- (or-red-cap-system-prob (state or_red_cap_system_prob_3)) 

?y <- (red-cap-system-prob (state thruster_systetn_p)) 

(retract ?x) 

(retract ?y) 

(assert (or-red-cap-system-prob (state or_red_cap_system_prob_4)))) 


(defrule red-cap-system-prob-50-s 
(declare (salience 6)) 

?x <- (or-red-cap-system-prob (state or_red_cap_system_prob_4)) 

?y <- (red-cap-system-prob (state Ieak_test_p)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (or-red-cap-system-prob (state or_red_cap_system_prob_5)))) 


(defrule red-cap-system-prob-11-s 

(or-red-cap-system-prob (state or_red_cap_system_prob_l)) 

=> 

(assert (red-cap-system-prob (state diving_system_p)))) 


(defrule red-cap-system-prob-11-end 
(declare (salience 10)) 

?x <- (or-red-cap-system-prob (state or_red_cap_system_prob_l)) 
?y <- (red-cap-system-prob (state diving_system_p)) 

(test (= (diving system p) 1)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (red-cap-system-prob (state done)))) 


(defrule red-cap-system-prob-21-s 

(or-red-cap-system-prob (state or_red_cap_system_prob_2)) 

=> 

(assert (red-cap-system-prob (state bouyancy_system_p)))) 


(defraile red-cap-system-prob-21 -end 
(declare (salience 9)) 
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?x <- (or-red-cap-system-prob (state or_red_cap_system_prob_2)) 
?y <- (red-cap-system-prob (state bouyancy_system_p)) 

(test (= (bouyancy_system_p) 1)) 

(retract ?x) 

(retract ?y) 

(assert (red-cap-system-prob (state done)))) 


(defirule red-cap-system-prob-31-s 

(or-red-cap-system-prob (state or_red_cap_system_prob_3)) 

=> 

(assert (red-cap-system-prob (state thruster_system_p)))) 


(defirule red-cap-system-prob-31-end 
(declare (salience 8)) 

?x <- (or-red-cap-system-prob (state or_red_cap_system_prob_3)) 
?y <- (red-cap-system-prob (state thruster_system_p)) 

(test (= (thruster_system_p) 1)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (red-cap-system-prob (state done)))) 


(defrule red-cap-system-prob-41-s 

(or-red-cap-system-prob (state or_red_cap_system_prob_4)) 

=> 

(assert (red-cap-system-prob (state leak_test_p)))) 


(defrule red-cap-system-prob-41-end 
(declare (salience 7)) 

?x <- (or-red-cap-system-prob (state or_red_cap_system_prob_4)) 
?y <- (red-cap-system-prob (state leak_test_p)) 

(test (= (leak_test_p) 1)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (red-cap-system-prob (state done)))) 
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(defrule rcd-cap-system*prob-51-s 

(or-red-cap-system-prob (state or_red_cap_system_prob_5)) 

=> 

(assert (red-cap-system-prob (state payload_prob_p)))) 


(defrule red-cap-system-prob-S 1-end 
(declare (salience 6)) 

?x <- (or-red-cap-system-prob (state or_red_cap_system_prob_5)) 
?y <- (red-cap-system-prob (state payload_prob_p)) 

(test (= (payload_prob_p) 1)) 

=> 

(retract ?x) 

(retract ?y) 

(assert (red-cap-system-prob (state done)))) 









3. TRACES OF THE EXECUTION OF THE SEARCH AND RESCUE MISSION 


The first trace represents the chain of inference derived from the logic embodied in 
the rule set of the Prolog and CLIPS programs for a complete, four-phase search_- 
and_rescue mission in which no environmental or systemic abnormalities were 
encountered. 

To start the mission using the backward-chaining Prolog implementation, a query 
“execute_auv_mission” is presented to the Prolog system. The inference engine 
searches the rule set for a rule head that matches this query and attempts to satisfy 
this mle’s subgoals in sequence from left to right: 

To start the mission using the forward-chaining CLIPS implementation, the (start) 
fact is first asserted to the fact-list, followed by the command (run). The CLIPS 
inference engine matches the current facts with the left-hand sides of the rules; 
responses to primitive goals are evaluated as part of the attempt to satisfy the con¬ 
ditional part of the rule. 

The traces listed herein are identical for both the Prolog and CLIPS implementa¬ 
tions. 


Entered the function ready_vehicIe_for_launch_p 
Entered the function select_first_waypoint 

Following initialization, the “transit” phase is entered: 

Entered the function in_transit_p 
Entered the function power_gone_p 
Entered the function computer_system_inop_p 
Entered the function propulsion_system_p 
Entered the function steering_system_inop_p 
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Entered the function gps„needed_p 
Entered the function reach_waypoint_p 
Entered the function diving_system„p 
Entered the function bouyancy_system_p 
Entered the function thruster_system_p 
Entered the function leak_test_p 
Entered the function payload_prob_p 
Entered the function unknown_obstacle_p 
Entered the function send_setpoints_and_modes 
Entered the function transit_done_p 
Entered the function in_transit_p 
Entered the function power_gone_p 
Entered the function computer„system_inop_p 

and so on, occasionally reaching the primitive goal “get_next_waypoint” when the 
query goal “reach_waypoint” receives a TRUE response. When the transit phase is 
complete, i.e., when the vehicle arrives at the search area, the search phase begins: 

Entered the function in_transit_p 
Entered the function in_search_p 
Entered the function do_search_pattem 
Entered the function search_done_p 
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When the target has been located and identified, the search phase ends and the task 
phase commences: 

Entered the function in_transit_p 
Entered the function in_search_p 
Entered the function in_task_p 
Entered the function homing 
Entered the function drop_package 
Entered the function get_^ps_fix 
Entered the function get_next_waypoint 
Entered the function task_done_p 

Finally, following the completipon of the task and subsequent gps location fix, the 
next waypoint is selected, corresponding to the first waypoint on the return path. 
This prepares the vehicle for the return phase of the mission: 

Entered the function in_transit_p 
Entered the function in_search_p 
Entered the function in_task_p 
Entered the function in_retum_p 
Entered the function power_gone_p 
Entered the function computer_system_inop_p 
Entered the ftinction propulsion_system_p 
Entered the function steering_system_inop_p 
Entered the function gps_needed_p 
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Entered the function reach_waypoint_p 
Entered the function diving_system_p 
Entered the function bouyancy_system_p 
Entered the function thruster_system_p 
Entered the function leak_test_p 
Entered the function payload_prob_p 
Entered the function unknown„obstacle_p 
Entered the function send_setpoints_and_modes 
Entered the function retum_done_p 
Entered the function in_transit_p 
Entered the function in_search_p 
Entered the function in_task_p 
Entered the function in_retum_p 

The logic used is precisely the same as the outbound transit, because the return is 
nothing more than a second transit phase. Therefore, this loop will also visit the 
primitive goal “get_next_waypoint” if multiple waypoints have been specified for 
the return leg of the journey. Upon reaching the final goal, the return phase is 
marked complete and the vehicle prepares itself for retrieval: 

Entered the function in_transit_p 
Entered the function in_search_p 
Entered the function in_task_p 
Entered the function in_retum_p 
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Entered the function power_gone_p 
Entered the function computer_system_inop_p 
Entered the function propulsion_system_p 
Entered the function steering_system_mop_p 
Entered the function gps_needed_p 
Entered the function reach_waypoint_p 
Entered the function diving_system_p 
Entered the function bouyancy_system_p 
Entered the function thruster_system_p 
Entered the function leak_test_p 
Entered the function payload_prob_p 
Entered the function unknown_obstacle_p 
Entered the function send_setpoints_and_modes 
Entered the function retum_done_p 
Entered the function wait_for_recovery 

By reaching this primitive goal, the inference engine completes its search. In the 
case of Prolog, the initial query is satisfied and the system responds with “yes” to 
indicate that the mission has been successfully completed. In CLIPS, the inference 
engine halts its search because no rules remain on the agenda. 

The next trace is generated &om the same rule sets and, hence, represent execution 
of the same mission. In this case, however, a problem involving the battery is 
encountered, resulting in a different sequence of primitive goals being generated. 

The mission is initiated and launched as before: 
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Entered the function ready_vehicle_for_launch_p 
Entered the function select_first_waypoint 
Entered the function in_transit_p 
Entered the function power_gone_p 
Entered the function computer_system_inop_p 
Entered the function propulsion_system_p 
Entered the function steering_systemJnop_p 
Entered the function gps_needed_p 
Entered the function reach_waypoint_p 
Entered the function diving_system_p 
Entered the function bouyancy_system_p 
Entered the function thruster_system_p 
Entered the function leak_test_p 
Entered the function payload_prob_p 
Entered the function unknown_obstacle_p 
Entered the function send_setpoints_and_modes 
Entered the function transit_done_p 
Entered the function in_transit_p 
Entered the function power_gone_p 
Entered the function computer_system_inop_p 
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At some point during the transit, the battery level drops below the threshold of 
acceptability and the order to surface is given; 

Entered the function computer_system_inop_p 
Entered the function propuIsion_system_p 
Entered the function steering_system_inop_p 
Entered the function gps_needed_p 
Entered the function reach_waypoint_p 
Entered the function diving_system_p 
Entered the function bouyancy_system_p 
Entered the function thruster_system_p 
Entered the function leak_test_p 
Entered the function payload_prob_p 
Entered the function unknown_obstacle_p 
Entered the function send_setpoints_and_modes 
Entered the function transit_done_p 
Entered the function in_transit_p 
Entered the function power_gone_p 
Entered the function surface 

At this point, control of the vehicle is turned over to the Tactical level. The Tactical 
level is then charged with issuing the appropriate commands to the Execution level 
which result in the desired action. For this implementation, once the vehicle 
reached the surface, communications links between the RBM levels were inter¬ 
rupted and the simulation stopped. Any number of alternatives are certainly possi- 
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ble, including initiation of a radio link or some other “SOS” signal. The Strategic 
level can be made to include this reasoning by adding the appropriate rules to its 
rule base. 









APPENDIX B. TACTICAL LEVEL SOURCE CODE 


- File: auv__ood_spec.ca 

- Author; Ron B. Byrnes 

- Date: 2 Oct 92 

- Revised: 15 Dec 92 

- System: Grus 

- Compiler: Classic-Ada, VADS 

" Description: Oversees the execution of the Tactical level. 

" Coordinates requests for information between the objects 

- of the object hierarchy. Provides the interface between 
" the Tactical level and the Strategic level. 

class AUV_OOD is 

method CREATE (NEW_AUV_OOD : out OBJECTJD); 
instance method IT'OTIALLZE; 

instance method L1NKUP_MM (POINTER : OBJECT^ID); 
instance method LINKUP_SR (POINTER : OBJECT_ID); 
instance method DELETE; 
instance method DOWNLOAD_OBSTACLES; 
instance method DOWNLOAD_INrnAL_STATE: 
instance method DOWNLOAD_WAYPOINTS; 
instance method DOWNLOAD_FINAL_GOAL; 
instance method SEL_IST_WP; 

instance method TRANSMIT_COMMAND (HEADING : in FLOAT; 
ZWP: in FLOAT; SPEED : in FLOAT; XWP : in FLOAT; 

YWP ; in FLOAT; MODE : in INTEGER); 
instance method SYS_CHECK (ANS : out INTEGER); 
instance method POWER_CHECK (ANS : out INTEGER); 
instance method SURFACE; 

instance method REACH.WAYPOINT (ANS : out BOOLEAN); 

instance method GET_NEXT_WP; 

instance method GET_VEH_POSTURE; 

instance method OBS^CHECK (ANS : out BOOLEAN); 

instance method PLAN; 

instance method EXECUTE_PLAN; 

instance method REACH_GOAL (ANS : out BOOLEAN); 

instance method NAV_OOD_BACKLINK(OOD : OBJECTJD); 

instance method ENGR_OOD JACKLINK(OOD : OBJECT_ID); 

instance method WEAP_OOD_BACKLINK(OOD : OBJECTJD); 

end AUV_OOD; 
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— File: auv_ood_body.ca 

— Author: Ron B. Byrnes 

— Date: 2 Oct 92 

— Revised: 15 Dec 92 

— System: Grus 

— Compiler: Classic-Ada, VADS 

— Description: Following creation, all dependent objects are 

— created as part of the initialization. Power model implemented, 

— which resides in ENGINEER 

with TEXT_IO, NAVIGATOR, ENGINEER, WEAPONS.OFHCER, 
COMMAND_SENDER, C_LIB; 
use TEXTJO, C_LIB; 

class body AUV_OOD is 

NAV : instance OBJECTJD; - instance of Navigator class 

ENGR : instance OB JECT_ID; -- instance of ENGINEER cl ass 

WEAP: instance OBJECTJD; - instance of WEAPONS.OFHCER class 

CMDS : instance OBJECT_ID; — instance of COMMAND„SENDER class 

MISS_MODEL : instance OBJECTJD; - pointer to MISSION_MODEL 

NUM_F, X, Y, Z, X JNIT, Y JNIT, Z JNIT, 

HEAD_INIT, SPEED_VAL, X_WAYPOINT, Y_WAYPOINT, 
Z_WAYPOINT, SPEED_WAYPOINT, CMD_HEADING : instance FLOAT; 
NUM J, MODE_NUM : instance INTEGER; 

method CREATE (NEW_AUV_OOD : out OBJECTJD) is 
begin 

NEW_AUV_OOD := instantiate; 

send (NEW_AUV_OOD, INITIALIZE); - initialize upon creation 
PUT_LINE(“AUV_OOD object is created!”); 

NEW_LINE; 
end CREATE; 

instance method INITIALIZE is 
begin 

NAV := NAVIGATOR.class_object; 
send(NAV, CREATE, new_navigator => NAV); 
send(NAV, GUI_NAV_BACKLINK, navig => NAV); 
send(NAV, GPS_NAV_BACKLINK, navig => NAV); 
send(NAV, SON_NAV_BACKLINK, navig => NAV); 
send(NAV, DR_NAV_BACKLINK, navig => NAV); 
send(NAV, MR_NAV_BACKLINK, navig => NAV); 

ENGR := ENGINEER.class_object; 
send(ENGR, CREATE, new_engineer => ENGR); 

WEAP := WEAPONS_OFFICER.class_object; 
send(WEAP, CREATE, new_weapons_officer => WEAP); 

CMDS COMMAND_SENDER.class_object; 
send(CMDS, CREATE, new_command_sender => CMDS); 
end INITIALIZE; 
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instance method NAV_OOD_BACKLINK (OOD ; OBJECTJD) is 
begin 

PUT_LINE(“Backlinking NAVIGATOR and OOD.”); 
send(NAV, PARENT_LINK, OOD => OOD); 
end NAV_OOD„BACKLINK; 

instance method ENGR_OOD„BACKLINK (OOD : OBJECT_ID) is 
begin 

PUT_LINE(“Backlinking ENGINEER and OOD.”); 
send(ENGR, PARENT_LINK, OOD => OOD); 
end ENGR_OOD_BACKLINK; 

instance method WEAP_OOD_BACKLINK (OOD ; OBJECT_ID) is 
begin 

PUT_LINE(“Backlinking WEAPONS^OFHCER and OOD.”); 
send(WEAP, PARENT_LINK, OOD => OOD); 
end WEAP_OOD_BACKLINK; 

instance method LINKUP_MM (POINTER : OBJECT_ID) is 
begin 

MISS_MODEL := POINTER; 

PUT_LINE(“Passing ptr to MM to NAV.”); 
send(NAV, LINKUP, MM => POINTER); 
end LINKUP_MM; 

instance method LINKUP_SR (POINTER; OBJECT_ID) is 
begin 

PUT_LINE(“Passing ptr to SR to NAV ”); 
send(NAV, LINK_SR, SR => POINTER); 
end LINKUP_SR; 

instance method DOWNLOAD_OBSTACLES is 
begin 

send(MISS_MODEL, GET_NUM_OBSTACLES, num_obs => NUM_I); 
NUM_F := FLOAT(NUM_I); PUT_LINEC‘ The number of obstacles is”); 
put_float(NUM_F); 

PUT_LINE(“ and the obstacles themselves:”); 
for I in l..NUM_I loop 

send(MISS_MODEL, GET_OBSTACLE, index => I, x.coord => X, 
y_coord => Y, z_coord => Z); 
put_float(X); 
put_float(Y); 
put_float(Z); 
end loop; 

end DOWNLOAD_OBSTACLES; 

instance method DOWNLOAD_INITIAL„STATE is 
begin 

send(MISS_MODEL, GETJNTTIAL.STATE, init.x => X_INIT, 
init_y => Y_INIT, init_z => Z_INIT, 
init_heading => HEAD_INrD; 
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put_float(X_INIT); 
put_float(Y_INIT); 
put_float(Z_INIT); 
put float(HEAD_INIT); 
end DOWNLOAD_INITIAL_STATE; 

instance method DOWNLOAD^WAYPOINTS is 
begin 

send(MISS_MODEL, GET_NUM_WAYPOINTS, num_wp => NUM_I); 

NUM_F := FLOAT(NUM_I); 

PUT_LINE(“ The number of waypoints is”); 
put_float(NUM_F); 

PUT_LIlfe(“ and the waypoints are:”); 
for I in L.NUM_I loop 

send(MISS_MODEL, GET_WAYPOINT, index => I, speed => SPEED_VAL, 
x__coord => X, y_coord => Y, z^coord => Z); 
put_float(SPEED_VAL); 
put_float(X); 
put_float(Y); 
put_float(Z); 
end loop; 

end DOWNLOAD_WAYPOINTS; 

instance method DOWNLOAD_FINAL_GOAL is 
begin 

send(MISS_MODEL, GET_FINAL_GOAL, x_final => X, y_final => Y); 

put_float(X); 

put_float(Y); 

end DOWNLOAD_FINAL_GOAL; 

instance method SEL_1ST_WP is 
begin 

send(NAV, LOAD_INrr„AND_GOAL_POSN); 

send(NAV, LOAD_WP, x_wp => X_WAYPOINT, y_wp => Y_WAYPOINT, 
z_wp => Z_WAYPOINT, sp^wp => SPEED_WAYPOINT); 
send(NAV, GET_HEADING, commanded_heading => CMD_HEADING); 
send(self, TRANSMIT_COMMAND, heading => CMD_HEADING, 
zwp => Z_WAYPOINT, speed => SPEED_WAYPOINT, 
xwp => X_WAYPOINT, ywp => Y_WAYPOINT, mode => MODE_NUM); 
PUT_LINE(“SEL_1ST_WP Done!”); 

NEW.LINE; 

NEW_LINE; 
end SEL_1ST_WP; 

instance method TRANSMIT.COMMAND (HEADING: FLOAT; ZWP; FLOAT; 

SPEED : FLOAT; XWP : FLOAT; YWP : FLOAT; MODE : INTEGER) is 
begin 

send(CMDS, SEND_COMMAND_PACKET, head_cmd => HEADING, 
z_cmd => ZWP, sp_cmd => SPEED, x_cmd => XWP, y_cmd => YWP, 
mode_cmd => MODE); 
end TRANSMIT_COMMAND; 
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instance method SYS_CHECK (ANS : out INTEGER) is 
begin 

send(ENGR, STATUS.REPORT, report => ANS); 
end SYS_CHECK; 

instance method POWER_CHECK (ANS ; out INTEGER) is 
begin 

send(ENGR, POWER_REPORT, report => ANS); 
end POWER_CHECK; 

instance method SURFACE is 
begin 

PUT_LINE(“Surfacing now,..”); 
for I in 1..25 loop 
send(self, GET_VEH_POSTURE); 
send(self, PLAN); 

send(self, TRANSMIT_COMMAND, heading => CMD_HEADING, zwp => 0.0, 
speed => 0.0, xwp => X_WAYPOINT, ywp => Y_WAYPOINT, 
mode => MODE_NUM); 
end loop; 
end SURFACE; 


instance method REACH_WAYPOINT (ANS : out BOOLEAN) is 
begin 

send(NAV. WP REACHED, result => ANS); 
end REACH_WAYPOINT; 

instance method GET_NEXT_WP is 
begin 

send(NAV, LOAD_WP, x_wp => X_WAYPOINT, y_wp => Y_WAYPOINT, 
z_wp => Z_WAYPOINT, sp_wp => SPEED.WAYPOINT); 
end GET_NEXT_WP; 

instance method GET_VEH_POSTURE is 
begin 

send(NAV, RECEIVE.POSN); 
send(NAV, RECEIVE_HEADING); 
send(NAV, RECEIVE_SPEED); 
end GET_VEH_POSTURE; 

instance method OBS_CHEClC (ANS ; out BOOLEAN) is 
begin 

send(NAV, CHECK_OBSTACLES, report => ANS); 
end OBS^CHECK; 

instance method PLAN is 
begin 

send(NAV, GET_HEADING, commanded_heading => CMD HEADING); 
end PLAN; 
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instance method EXECUTE_PLAN is 
begin 

send(self, TRANSMIT_COMMAND, heading => CMD_HEADING, 
zwp => Z^WAYPOINT, speed => SPEED_WAYPOINT, xwp => X_WAYPOINT, 
ywp => Y_WAYPOINT, mode => MODE_NUM); 
end EXECUTE_PLAN: 

instance method REACH_GOAL (ANS : out BOOLEAN) is 
begin 

send(NAV, CHECK_GOAL, report => ANS); 
end REACH^GOAL; 

instance method DELETE is 
begin 

send(NAV, DELETE); 
send(ENGR, DELETE); 
send(WEAP, DELETE); 
send(CMDS, DELETE); 

PUT_LINE(“auv_ood object destroyed!”); 
destroy; 
end DELETE; 

end AUV_OOD; 
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- File: navigator_spec.ca 
Author: Ron B. Byrnes 

- Date: 2 Oct 92 

- Revised : 24 Nov 92 

- System: Grus 

- Compiler: Classic-Ada, VADS 

- Description: Responsible for the steering and location of the 

- vehicle. 

class NAVIGATOR is 

method CREATE (NEW_NAVIGATOR : out OBJECT_ID); 
instance method IMTIALIZE; 

instance method GUI_NAV_BACKLINK (NAVIG : OBJECTJD); 

instance method GPS_NAV_BACKLINK (NAVIG : OBJECTJD); 

instance method SONINAV_BACKLINK (NAVIG : OBJECTJD); 

instance method DR_NAV_BACKLINK (NAVIG : OBJECTJD); 

instance method MR_NAV_BACKLINK (NAVIG : OBJECTJD); 

instance method PARENT_LINK (OOD: OBJECT^ID); 

instance method LINKUP(MM ; OBJECTJD); 

instance method LINK_SR (SR : OBJECTJD); 

instance method LOADJNIT_AND_GOAL_POSN; 

instance method LOAD_WP (X_WP: out FLOAT; Y_WP : out FLOAT; 

Z_WP ; out FLOAT; SP_WP : out FLOAT); 

instance method GET_HEADING (COMMANDED_HEADING : out FLOAT); 

instance method WP_REACHED (RESULT: out BOOLEAN); 
instance method RECEFVE.POSN; 
instance method RECEIVE_HEADING; 
instance method RECEIVE^SPEED; 

instance method CHECK.OBSTACLES (REPORT: out BOOLEAN); 
instance method CHECK_GOAL (REPORT : out BOOLEAN); 

instance method DELETE; 

end NAVIGATOR; 
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— File: navigator_body.ca 

— Author: Ron B. Byrnes 

— Date: 2 Oct 92 

— Revised: 24 Nov 92 

— System: Grus 

— Compiler: Classic-Ada, VADS 

— Description; Instantiates dependent objects upon initialization. 

with TEXT JO, GUIDANCE, GPS_CONTROL, SONAR_CONTROL, DEAD_RECK- 
ONING, 

MISSION_REPLANNER, MATH; 
use TEXT JO, MATH; 

class body NAVIGATOR is 

package FLOATJNOUT is new FLOATJO(FLOAT); 
use FLOAT_INOUT; 

GUIDE : instance OB JECT_ID; -- Instance of GUIDANCE class 
GPS : instance OBJECT_ID; — Instance of GPS_CONTROL clas s 
SONAR: instance OBJECT_ID; - Instance of SONAR_CONTROL class 
DR : instance OBJECT_ID; — Instance of DEAD_RECKONING class 
REPLAN: instance OBJECT_ID; -- Instance of MISSION_REPLANNER class 
OOD_HANDLE; instance OBJECTJD; 

MISS_MODEL : instance OBJECT_ID; 

SENSORY_RECEIVER: instance OBJECTJD; 

x_posrnoN, y_position, z^position, 

X_WAYPOINT, Y_WAYPOINT, Z_WAYPOINT, X_GOAL, Y_GOAL, 

UNNEEDED, CALC, WP_THRESHOLD, 

TRUE_SPEED, TRUE_HEADING ; instance FLOAT; 

WP_INDEX; instance INTEGER; 


method CREATE (NEW_NAVIGATOR : out OBJECTJD) is 
begin 

NEW_NAVIGATOR := instantiate; 

send (NEW_NAVIGATOR, INITIALIZE); - initialize upon creation 
PUT_LINE(“Navigator object is created!”); 

NEW_LINE; 
end CREATE; 

instance method INITIALIZE is 
begin 

GUIDE := GUIDANCE,class_object; 
send(GUIDE, CREATE, new_guidance => GUIDE); 
send(GUIDE, LOS_GUI_BACKLINK, pointer => GUIDE); 

GPS := GPS_CONTROL.class_object; 
send(GPS, CREATE, new ,gps control => GPS); 

SONAR := SONAR_CONTROL.class_object; 
send(SONAR, CREATE, new_sonar_control => SONAR); 
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DR := DEAD_RECKONING.class_object; 
send(DR, CREATE, new_dead_reckoning => DR); 

REPLAN := MISSION_REPLANNER.class_object; 
send(REPLAN, CREATE, new_mission_replanner => REPLAN); 
WP_INDEX := 0; 

WP_THRESHOLD ;= 20.0; 
end INITIALIZE; 

instance method GUI_NAV_BACKLINK (NAVIG : OBJECTJD) is 
begin 

PUT_LINE(“Backlinking GUIDANCE and NAVIGATOR.”); 
send(GUIDE, PARENT_LINK, pointer_gn => NAVIG); 
end GU1_NAV_BACKLINK; 

instance method GPS_NAV_BACKLINK (NAVIG; OBJECT_ID) is 
begin 

PUT_LINE(“Bacldinking GPS_CONTROL and NAVIGATOR.”); 
send(GPS, PARENT_LINK, pointer_gpsn => NAVIG); 
end GPS.NAV^ACKLINK; 

instance method SON_NAV_BACKLINK (NAVIG : OBJECTJD) is 
begin 

PUT_LINE(“Backlinking SONAR_CONTROL and NAVIGATOR.”); 
send(SONAR, PARENT^LINK, pointer_sn => NAVIG); 
end SON_NAV_BACKLINK; 

instance method DR_NAV_BACKLINK (NAVIG : OBJECT.ID) is 
begin 

PUT_LINE(“BacldinJdng DEAD.RECKONING and NAVIGATOR.”); 
send(DR, PARENT.LINK, pointer_dr => NAVIG); 
end DR_NAV_BACKLINK; 

instance method MR_NAV_BACKLINK (NAVIG : OBJECTJD) is 
begin 

PUT_LINE(“Backlinking MISSION.REPLANNER and NAVIGATOR.”); 
send(REPLAN, PARENT_LINK, pointer_mn => NAVIG); 
end MR_NAV_BACKLINK; 

instance method PARENT_LINK (OOD : OBJECT_ID) is 
begin 

PUT_LINE(“OOD reached NAVIG.”); 

OOD_HANDLE := OOD; 
end PARENT_LINK; 

instance method LINKUP(MM : OBJECTJD) is 
begin 

PUT_LINE(“rm passing MM to GUIDANCE.”); 
send(GUIDE, LII^UP, miss__model => MM); 

MISS_MODEL := MM; 
end LINKUP; 
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instance method LINK_SR (SR : OBJECT_ID) is 
begin 

SENSORY_RECEIVER := SR; 

PUT_LINE(“Nav got ptr to SR.”); 
end LINK_SR; 

instance method LOAD_INTT_AND_GOAL_POSN is 
begin 

send(MISS_MODEL, GET_INITIAL_STATE, init_x => X_POSITION, 

init_y => Y_POSI'nON, init_z => Z_POSITION, init_heading => UNNEEDED); 
send(MISS_MODEL, GET_FINAL_GOAL, x_final => X_GOAL, y_final => Y_GOAL); 
end LOAD_INIT_AND_GOAL_POSN; 

instance method LOAD_WP (X_WP : out FLOAT; Y_WP ; out FLOAT; 

Z_WP ; out FLOAT; SP_WP : out FLOAT) is 
begin 

WP_INDEX := WPJNDEX + 1; 

send(MISS_MODEL, GET_WAYPOINT, index => WP_INDEX, speed => SP_WP, 
x_coord => X_WP, y_coord => Y_WP, z_coord => Z_WP); 

X_WAYPOINT ;= X_WP; 

Y_WAYPOINT := Y_WP; 

Z_WAYPOINT := Z_WP; 
end LOAD.WP; 

instance method GET_HEADING (COMMANDED.HEADING : out FLOAT) is 
begin 

sendCGUIDE, GET_HEADING, calculated_heading => COMMANDED_HEADING, 
x_posn => X_POSrnON, y_posn => Y_POSITION, z_posn => Z^POSITION, 
x_waypt => X_WAYPOINT, y.waypt => Y_WAYPOINT, 
z_waypt => Z_WAYPOINT); 
end GET.HEADING; 


instance method WP_REACHED (RESULT : out BOOLEAN) is 
begin 

CALC := SQRT((X_WAYPOINT - X_POSITION)**2 + 
(Y_WAYPOINT - Y_POSITION)**2); 
if CALC < WP THRESHOLD then 
RESULT := TRUE; 

PUTC'Waypoint reached is (X,Y,Z): “); 

PUT(X_WAYPOINT, fore => 5, aft => 2, exp => 0); 
PUT(Y_WAYPOINT, fore => 5, aft => 2, exp => 0); 
PUT(Z_WAYPOINT, fore => 5 , aft => 2, exp => 0); 
NEW_LINE; 

Put(“Actual X, Y, depth, and heading :”); 

PUT(X_POSITION, fore => 5, aft => 2, exp => 0); 
PUT(Y_POSITION, fore => 5, aft => 2, exp => 0); 
PUT(Z_POSITION, fore => 5, aft => 2, exp => 0); 
PUT(TRUE_HEADING, fore => 5, aft => 2, exp => 0); 
NEWSLINE; 
else 
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RESULT := FALSE; 
end if; 

end WP_REACHED; 

instance method RECErVE_POSN is 
begin 

send(SENSORY„RECErVER, GET_CURRENT_POSN, x => X.POSITION, 
y => Y_POSrnON, z => Z_POSrnON); 
end RECEIVE.POSN; 

instance method RECEIVE_HEADING is 
begin 

send(SENSORY_RECEIVER,GET_CURRENT_HEADING, 
head => TRUE_HEADING); 
end RECEIVE_HEADING; 

instance method RECEIYE_SPEED is 
begin 

send(SENSORY_RECEIVER, GET_CURRENT_SPEED, speed => TRUE^SPEED); 
end RECEIVE_SPEED; 

instance method CHECK_OBSTACLES (REPORT : out BOOLEAN) is 
begin 

send(SONAR, OBSTACLE_STATUS, status => REPORT); 
end CHECK_OBSTACLES; 

instance method CHECK_GOAL (REPORT: out BOOLEAN) is 
begin 

CALC := SQRT((X_GOAL - X_POSITION)**2 + 

(Y_GOAL - Y_POSmON)**2); 
if CALC < WP_THRESHOLD then 
REPORT ;= TRUE; 

PUT(“Final Goal reached is (X,Y,Z): “); 

PUT(X_GOAL, fore => 5, aft => 2, exp => 0); 

PUT(Y_GOAL, fore => 5, aft => 2 , exp => 0); 

NEW_LINE; 

Put(“Actual X, Y, depth, and heading :”); 

PUT(X_POSITION, fore => 5, aft => 2, exp => 0); 

PUT(Y_POSITION, fore => 5, aft => 2, exp => 0); 

PUT(Z_POSmON, fore => 5, aft => 2, exp => 0); 

PUT(TRUE_HEADING, fore => 5, aft => 2, exp => 0); 

NEW_Ln^; 

else 

REPORT := FALSE; 
end if; 

end CHECK_GOAL; 


instance method DELETE is 
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begin 

send(GUlDE, DELETE); 
send(GPS, DELETE); 
send(SONAR, DELETE); 
send(DR, DELETE); 
send(REPLAN, DELETE); 

PUT_LINE(“Navigator object going down...!”); 

destroy; 

end DELETE; 

end NAVIGATOR; 
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— File: guidance^spec.ca 

— Author: Ron B. Byrnes 

— Date: 2 Oct 92 

— Revised: 16 Nov 92 
” System: Grus 

-- Compiler: Classic-Ada, VADS 

— Description: Responsible for the calculation of heading 
-- commands. 

class GUIDANCE is 

method CREATE (NEW_GUIDANCE : out OBJECTJD); 
instance method IMTIALIZE; 

instance method PARENT_UNK (POINTER_GN : OBJECTJD); 
instance method LINKUP (MISS_MODEL: OBJECT_ID); 
instance method LOS_GUI_BACKLINK (POINTER : OBJECT_ID); 
instance method GET_HEADING (CALCULATED HEADING : out FLOAT; 

X_POSN, Y_POSN, Z_POSN, X_WAYPT, Y_WAYPT, Z_WAYPT: in FLOAT); 
instance method DELETE; 

end GUIDANCE; 
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File; guidance_bociy.ca 
Author: Ron B. Byrnes 

— Date: 2 Oct 92 

— Revised: 16 Nov 92 

— System: Grus 

— Compiler: Classic-Ada, VADS 

Description: Instantiates “dependent” objects upon initialization. 

with TEXT JO, LOS^CALCULATOR; 
use TEXT JO; 

class body GUIDANCE is 

LOS ; instance OBJECT_ID; 

NAVIG_HANDLE : instance OBJECT_ID; 

method CREATE (NEW_GUIDANCE : out OBJECT_ID) is 
begin 

NEW_GUIDANCE := instantiate; 

send (NEW^GUIDANCE, INITIALIZE); — intialize upon creation 
PUT_LINE(“Guidance object is created!”); 

NEWSLINE; 
end CREATE; 

instance method INITIALIZE is 
begin 

LOS := LOS_CALCULATOR.class_object; 
send(LOS, CREATE, newJos_calculator => LOS); 
end INITIALIZE; 

instance method GET_HEADING (CALCULATED_HEADING : out FLOAT; 
X_POSN, Y_POSN, Z_POSN, X_WAYPT, Y„WAYPT, Z_WAYPT : in FLOAT) is 
begin 

send(LOS, GET_NEW_HEADING, heading_seUpoint => CALCULATED_HEADING, 
xcurr => X_POSN, ycurr => Y_POSN, zcurr => Z_POSN, 
xnext => X_WAYPT, ynext => Y_WAYPT, znext => Z_WAYPT); 
end GET_HEADING; 

instance method PARENT_LINK (POINTER„GN ; OBJECT_ID) is 
begin 

PUT_LINEC‘NAVIG reached GUIDE.”); 

NAVIG_HANDLE := POINTER_GN; 
end PARENT_LINK; 

instance method LOS_GUI_B ACKLINK:(P0INTER : OBJECT.ID) is 
begin 

PUT_LINEC‘Backlinking LOS and GUIDANCE.”); 
send(LOS, PARENT_LINK, guide => POINTER); 
end LOS_GUI_BACKLINK; 

instance method LINKUP(MISS_MODEL : OBJECT_ID) is 
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begin 

PUT_LINE(“rm passing ptr to MISS_MODEL to LOS.”); 
send(LOS, LINKUP, MM => MISS_MODEL); 
end LINKUP; 

instance method DELETE is 
begin 

send(LOS, DELETE); 

PUT_LINE(“Guidance object going down!”); 

destroy; 

end DELETE; 

end GUIDANCE; 
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— File: gps_control_spec.ca 

— Author: Ron B. Byrnes 

— Date: 5 Oct 92 

— Revised 25 Nov 92 

— System: Grus 

— Compiler: Classic-Ada, VADS 

— Description: Generates commands to activate/deactivate gps 

— package. Obtains and analyzes readings. Provides positional 

— information derived from those readings. 

class GPS_CONTROL is 

method CREATE (NEW_GPS_CONTROL : out OBJECTJD); 
instance method IMTIALIZE; 

instance method PARENT_LINK (POINTER_GPSN : OBJECT_ID); 
instance method DELETE; 


end GPS.CONTROL; 





— File: gps_control_body.ca 

— Author: Ron B. Byrnes 

— Date: 5 Oct 92 

— Revised: 25 Nov 92 

— System: Grus 

— Compiler: Classic-Ada, VADS 

— Description: 

with TEXT JO; 
use TEXT JO; 

class body GPS_CONTROL is 

NAVIG_HANDLE: instance OBJECT_ID; 

method CREATE (NEW_GPS_CONTROL : out OBJECTJD) is 
begin 

NEW_GPS_CONTROL := instantiate; 

send (NEW_GPS_CONTROL, INITIALIZE); - initialize upon creation 
end CREATE; 

instance method INITIALIZE is 
begin 

PUT_LINE(“GPS Control instantiated.”); 
end INITIALIZE; 

instance method PARENT_LINK (POINTER_GPSN; OBJECT_ID) is 
begin 

PUT_LINE(“NAVIG reached GPS.”); 

NAVIG_HANDLE := POINTER_GPSN; 
endPARENT_LINK; 

instance method DELETE is 
begin 

PUT_LINE(“GPS Control being deallocated now.”); 

destroy; 

end DELETE; 

end GPS_CONTROL; 
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— File: sonar_control_spec.ca 
-- Author: Ron B. B5n:nes 

— Date: 5 Oct 92 

— Revised: 25 Nov 92 

— System: Grus 

— Compiler: Classic-Ada, VADS 

— Description: Activates/deactivates sonar(s), takes readings 

— from sonars and determines location and identification of 

— objects; provides vehicle position in conjunction with 

— the world model. 

class SONAR_CONTROL is 

method CREATE (NEW_SONAR_CONTROL: out OBJECT_ID); 
instance method IMTIALIZE; 

instance method PARENT_LINK (POINTER_SN : 0BJECT_1D); 
instance method OBSTACLE_STATUS (STATUS : out BOOLEAN); 
instance method DELETE; 


end SONAR_CONTROL; 


-- File: sonar_control_body.ca 
“ Author: Ron B. Byrnes 

— Date: 5 Oct 92 

— Revised 25 Nov 92 

— System: Grus 

— Compiler: Classic-Ada, VADS 

— Description: 

with TEXTJO; 
use TEXTJO; 

class body SONAR_CONTROL is 

NAVIG.HANDLE: instance 0BJECT_1D; 

method CREATE (NEW_SONAR_CONTROL : out OBJECT_ID) is 
begin 

NEW_SONAR_CONTROL := instantiate; 

send (NEW_SONAR_CONTROL, INITIALIZE); — initialize upon creation 
end CREATE; 

instance method INITIALIZE is 
begin 

PUT_LINE(“Sonar Controller has been instantiated.”); 
end INITIALIZE; 

instance mediod PARENT_LINK (POINTER_SN : OBJECT_ID) is 
begin 

PUT_LINE(“NAVIG reached SONAR.”); 

NAVIG_HANDLE := POINTER_SN; 
end PARENT_LINK; 

instance method OBSTACLE.STATUS (STATUS : out BOOLEAN) is 
begin 

STATUS := FALSE; ~ Obstacle identification algorithm goes here 
end OBSTACLE_STATUS; 

instance method DELETE is 
begin 

PUT_LINE(“Sonar control going down.”); 

destroy; 

end DELETE; 

end SONAR_CONTROL; 


212 







— File: dead_reckoning_spec.ca 

— Author: Ron B. Byrnes 
-- Date: 5 Oct 92 

-- Revised: 24 Nov 92 
-- System: Gras 

— Compiler: Classic-Ada, VADS 

— Description: Determines vehicle position by dead reckoning 
class DEAD_RECKONING is 

method CREATE (NEW_DEAD_RECKONING : out OBJECT_ID); 
instance method IMTIALIZE; 

instance method PARENT_LINK (POINTER_DR : OBJECT_ID); 
instance method DELETE; 

end DEAD_RECKONING; 
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— File; dead_reckoning_body.ca 

— Author: Ron B. Byrnes 

— Date; 5 Oct 92 

— Revised: 24 Nov 92 

— System: Grus 

— Compiler; Classic-Ada, VADS 

— Description: Will estimate vehicle location in the X-Y 

— plane using dead reckoning. Required parameters 

— will be obtained from the Sensory Receiver (the 

— link to which needs to be established). 

with TEXT JO; 
use TEXT JO; 

class body DEAD_RECKONING is 
NAVIG_HANDLE: instance OBJECT^ID; 

method CREATE (NEW_DEAD_RECKONING : out OBJECT_ID) is 
begin 

NEW_DEAD_RECK0N1NG ;= instantiate; 

send (NEW_DEAD_RECKONING, INITIALIZE); — initialize upon creation 
end CREATE; 

instance method INITIALIZE is 
begin 

PUT_LINE(“Dead Reckoner object created.”); 
end INITIALIZE; 

instance method PARENT_LINK (POINTER_DR : OBJECTJD) is 
begin 

PUT_LINE(“NAVIG reached DR.”); 

NAVIG.HANDLE := POINTER_DR; 
endPARENT_LINK; 

instance method DELETE is 
begin 

PUT_LINE(“Dead Reckoner being destroyed.”); 

destroy; 

end DELETE; 

end DEAD.RECKONING; 
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— File: mission_replanner_spec.ca 

— Author; Ron B. Byrnes 

— Date: 5 Oct 92 

— Revised: 25 Nov 92 

— System: Gras 

— Compiler: Classic-Ada, VADS 

— Description: Performs local replanning (obstacle avoidance) and 

— global replanning (fault tolerance) as directed. 

class MISSION_REPLANNER is 

method CREATE (NEW_MISSION_REPLANNER : out OBJECTJD); 
instance method INITIALIZE; 

instance method PARENT_LINK (POINTER_MN : OBJECTJD); 
instance method DELETE; 

end MISSION_REPLANNER; 
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— File: niission_replanner_body.ca 
-- Author: Ron B, Byrnes 

— Date: 5 Oct 92 

— Revised: 25 Nov 92 

— System: Grus 

— Compiler: Classic-Ada, VADS 

— Description: 

with TEXT_IO; 
use TEXT_IO; 

class body MISSION_REPLANNER is 
NAVIG_HANDLE: instance OBJECT_ID; 

method CREATE (NEW_M1SSI0N_REPLANNER: out OBJECTJD) is 
begin 

NEW_MISSION_REPLANNER := instantiate; 

send (NEW_MISSION_REPLANNER, INITIALIZE); - initiaUze upon creation 
end CREATE; 

instance method INITIALIZE is 
begin 

PUT_LINE(“Mission Replanner object created.”); 
end INITIALIZE; 

instance method PARENT_LINK (POINTER_MN ; OBJECTJD) is 
begin 

PUT_LINE(“NAVIG reached REPLAN.”); 

NAVIG.HANDLE := POINTER_MN; 
end PARENT.LINK; 

instance method DELETE is 
begin 

PUT_LINE(“Mission Replanner going down.”); 

destroy; 

end DELETE; 

end MISSION.REPLANNER; 
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— File: engineer_spec.ca 

— Author: Ron B. Byrnes 

— Date: 5 Oct 92 

— Revised: 15 Dec 92 

— System: Grus 

— Compiler: Classic-Ada, VADS 

— Description: 

class ENGINEER is 

method CREATE (NEW_ENGINEER : out OBJECT_lD); 
instance method IMTTALIZE; 

instance method PARENT_LlNK(OOD : OBJECTJD); 
instance method STATUS_REPORT (REPORT: out INTEGER); 
instance method POWER_REPORT (REPORT : out INTEGER); 
instance method DELETE; 


end ENGINEER; 


— File: engineer_body.ca 
Author: Ron B. Byrnes 

— Date: 5 Oct 92 

— Revised: 15 Dec 92 
-- System: Gras 

-- Compiler: Classic-Ada, VADS 

— Description: Responsible for the monitoring and health of the vehicle’s 
“ subsystems. Battery model resides here. 

with TEXTJO; 
use TEXTJO; 


class body ENGINEER is 
OOD_HANDLE : instance OBJECTJD; 

BATTERY : instance FLOAT; 

method CREATE (NEW_ENGINEER: out OBJECT JD) is 
begin 

NEW_ENGINEER := instantiate; 

send (NEW_ENGINEER, INITIALIZE); -- initialize upon creation 
end CREATE; 

instance method INITIALIZE is 
begin 

BATTERY := 24.0; 

PUT_LINE(“Engineer has been created.”); 
end INITIALIZE; 

instance method PARENT_LINK (OOD : OBJECT JD) is 
begin 

PUT_LINE(“OOD reached ENGR.”); 

OOD_HANDLE := OOD; 
end PARENT_LINK; 

instance method STATUS_REPORT (REPORT: out INTEGER) is 
begin 

~ read and compare various systems parameters 
- Devise a listing of codes, each associated with a particular system fault. 
REPORT ;= 1; 
end STATUS_REPORT; 

instance method POWER_REPORT (REPORT: out INTEGER) is 
begin 

BATTERY := BATTERY - 0.08; 
if BATTERY <18.0 then 
REPORT := 0; 
else 

REPORT := 1; 
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end if; 

end POWER_REPORT; 

instance method DELETE is 
begin 

PUT_LINE(“Engineer being destroyed”); 

destroy; 

end DELETE; 

end ENGINEER; 
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- File: weapons_officeT_spec.ca 

- Author: Ron B. Byrnes 

- Date: 5 Oct 92 

- Revised: 16 Nov 92 
-- System: Grus 

“ Compiler: Classic-Ada, VADS 

- Description: Responsible for the deployment of the vehicle’s 

- payload(s). 

class WEAPONS_OFnCER is 

method CREATE (NEW_WEAPONS_OFFICER: out OBJECTED); 
instance method IMTIALIZE; 

instance method PARENT_LINK(OOD : OBJECTJD); 
instance method DELETE; 

end WEAPONS_OFnCER; 
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— File: weapons_officer_body.ca 

— Author: Ron B. Byrnes 

— Date: 5 Oct 92 

— Revised 16 Nov 92 

— System: Grus 

— Compiler: Classic-Ada, VADS 

— Description: 

with TEXTJO; 
use TEXT_IO; 

class body WEAPONS_OFnCER is 
OOD_HANDLE: instance OBJECT_ID; 

method CREATE (NEW_WEAPONS_OFFICER : out OBJECT_ID) is 
begin 

NEW_WEAPONS_OFnCER := instantiate; 

send (NEW_WEAPONS_OFFICER, INITTALIZE); — initialize upon creation 
end CREATE; 

instance method INITIALIZE is 
begin 

PUT_LINE(“Weapons Officer created.”); 
end INITIALIZE; 

instance method PARENT_LINK (OOD : OBJECTJD) is 
begin 

PUT_LINE(“OOD reached WEAPONS.”); 

OOD_HANDLE := OOD; 
end PARENT_LINK; 

instance method DELETE is 
begin 

PUT_LINEC‘Weapons officer destroyed.”); 

destroy; 

end DELETE; 

end WEAPONS_OFnCER; 
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— File; command_sender_spec.ca 

— Author: Ron B. Byrnes 
“ Date: 5 Oct 92 

— Revised: 23 Nov 92 
” System: Grus 

— Compiler: Classic-Ada, VADS 

— Description: Collects all commands (setpoints) pertaining to the 

— current mode and needed to drive the autopilots located in the 

“ Execution level. Builds a command packet using these individual 
“ commands and sends the packet to the command port. 

class COMMAND_SENDER is 

method CREATE (NEW_COMMAND_SENDER : out OBJECT_ID); 
instance method IMTIALIZE; 

instance method SEND_COMMAND_PACKET (HE AD_CMD: in FLOAT; 
Z_CMD : in FLOAT; SP_CMD : in FLOAT; X_CMD : in FLOAT; 
Y_CMD : in FLOAT; MODE_CMD : in INTEGER); 
instance method DELETE; 

end COMMAND_SENDER; 
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— File: command_sender_body.ca 

— Author: Ron B. B3Tnes 
-- Date: 5 Oct 92 

— Revised: 13 Dec 92 
" System: Grus 

Compiler: Classic-Ada, VADS 
-- Description: 


with TEXT_IO, C_L1B; 
use TEXTJO, C_LIB; 

class body COMMAND_SENDER is 

package FLOATJNOUT is new FLOAT_IO(FLOAT); 
use FLOAT_INOUT; 

method CREATE (NEW_COMMAND_SENDER : out OBJECTJD) is 
begin 

NEW_COMMAND_SENDER := instantiate; 
send (NEW_COMMAND_SENDER, INITIALIZE); 
end CREATE; 

instance method INITIALIZE is 
begin 

PUT_LINE(“Command sender has been created and initialized.”); 
end INITIALIZE; 

instance method SEND_COMMAND_PACKET (HEAD.CMD : in FLOAT; 
Z_CMD : in FLOAT; SP_CMD : in FLOAT; X_CMD : in FLOAT; 
Y_CMD : in FLOAT; MODE_CMD : in INTEGER) is 
begin 

puC.float(HEAD_CMD); 

put_float(Z_CMD); 

put_float(SP_CMD); 

put_float(X_CMD); 

put_float(Y_CMD); 

put_mode(MODE_CMD); 

end SEND_COMMAND_PACKET; 

instance method DELETE is 
begin 

PUT_LINE(“Command Sender is going down.”); 

destroy; 

end DELETE; 

end COMMAND_SENDER; 
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-- File: sensory_receiver_spec.ca 

— Author: Ron B. Bymes 

— Date: 8 Oct 92 

— Revised 25 Nov 92 

— System: Grus 

~ Compiler: Classic Ada, VADS 

— Description: Accepts telemetry from Execution level; breaks out 

— individual sensor readings from packet and stores in locations 

— accessable by using objects 

class SENSORY_RECEIVER is 

method CREATE (NEW_SENSORY_RECEIVER: out OBJECTJD); 

instance method IMTIALIZE; 

instance method LINKUP_DR (DR : in OBJECTJD); 

instance method GET_CURRENT_POSN (X, Y, Z : out FLOAT); 

instance method GET_CURRENT_HEADING (HEAD : out FLOAT); 

instance method GET_CURRENT_SPEED (SPEED : out FLOAT); 

instance method DELETE; 

end SENSORY_RECEIVER; 
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— File; sensory_receiver_body.ca 

— Author: Ron B. Byrnes 

— Date; 8 Oct 92 

-- Revised: 12 Jan 93 
-- System: Grus 

— Compiler: Classic Ada, VADS 

— Description: Defines the external interface of the object 

with TEXTJO, C_LIB; 
use TEXTJO, C_L1B; 

class body SENSORY^RECEIVER is 

DATA_REC : instance OBJECT_ID; — pointer to DATA RECORDER 
ALT: instance FLOAT; 

package FLOAT_INOUT is new FLOAT_IO(FLOAT); 
use FLOAT_INOUT; 

method CREATE (NEW_SENSORY_RECEIVER : out OBJECTJD) is 
begin 

NEW_SENSORY_RECEIVER := instantiate; 
send (NEW_SENSORY_RECEIVER, INITIALIZE); 
end CREATE; 

instance method INITIALIZE is 
begin 

PUT_LINE(“Sensory Receiver created.”)! 
end INITIALIZE; 

instance method LINKUP_DR (DR : in OBJECTJD) is 
begin 

DATA_REC := DR; 

PUT_LINE(“SR knows about DR.”); 
end LINKUP.DR; 

instance method GET_CURRENT_POSN (X, Y, Z : out FLOAT) is 
begin 

X := get_float; 

Y := get_float; 

ALT := get_float; 

Z := get_float; 

end GET_CURRENT_POSN; 

instance method GET_CURRENT_HEADING (HEAD : out FLOAT) is 
begin 

HEAD := get_float; 

end GET_CURRENT_HEADING; 

instance method GET_CURRENT_SPEED (SPEED: out FLOAT) is 
begin 
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SPEED := 0.0; — Speed isn’t obtained from this version of the auvsim 
end GET_CURRENT_SPEED; 


instance method DELETE is 
begin 

PUT_LINE(“Sensory receiver destroyed.”); 

destroy; 

end DELETE; 

end SENSORY_RECEIVER; 
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— File: mission_model_spec.ca 

— Author: Ron B, Byrnes 

- Date: 8 Oct 92 

-- Revised: 23 Nov 92 

- System: Grus 

- Compiler: Classic Ada, VADS 

— Description: A data base containing the various mission parameters 


class MISSION_MODEL is 

method CREATE (NEW_MrSSrON_MODEL: out OBJECT_ID); 
instance method INITIALIZE; 

instance method GET_NUM_OBSTACLES (NUM_OBS : out INTEGER); 
instance method GET_OBSTACLE (INDEX : in INTEGER; 

X_COORD : out FLOAT; Y_COORD : out FLOAT; 

Z_COORD; out FLOAT); 

instance method GET_INITIAL_STATE (INIT_X : out FLOAT; 

INIT_Y ; out FLOAT; INIT_Z : out FLOAT; 

INIT_HEADING : out FLOAT); 

instance method GET_NIJM_WAYPOINTS (NUM_WP : out INTEGER); 
instance method GET_WAYPOINT (INDEX ; in INTEGER; 

SPEED : out FLOAT; X_COORD : out FLOAT; 

Y_COORD : out FLOAT; Z_COORD : out FLOAT); 
instance method GET_nNAL_GOAL (X_FINAL : out FLOAT; 

Y_FINAL: out FLOAT); 

instance method GET_NEXT_WP (XWP; out FLOAT; YWP; out FLOAT); 
instance method DELETE; 


end MISSION_MODEL; 






“ File: mission_niodel_body.ca 

— Author: Ron B. Byrnes 

— Date: 8 Oct 92 

— Revised: 15 Dec 92 

— System: Grus 

— Compiler: Classic Ada, VADS 

— Description: 

with TEXTJO; 
use TEXTJO; 

class body MISSION_MODEL is 

OBSTACLE_LIST: ARRAY (1..4,1..3) of FLOAT := 

((350.0,350.0,50.0), 

(70.0,1330.0,50.0), 

(630.0,1330.0,50.0), 

(350.0,1050.0,50.0)); 

— Waypoints are arranged (speed, x, y, z) 

WAYPOINT.LIST: ARRAY (1..12,1..4) of FLOAT := 

(( 300.0, 350.0,100.0,10.0), 

(300.0, 500.0,250.0, 30.0), 

(300.0, 500.0, 500.0,35.0), 

(300.0, 350.0,700.0,40.0), 

(300.0, 200.0,900.0,40.0), 

(300.0,200.0,1150.0,12.0), 

(300.0,350.0,1300.0,20.0), 

(300.0,500.0,1150.0,30.0), 

(300.0,500.0, 900.0,40.0), 

(300.0, 350.0,700.0, 50.0), 

(300.0, 200.0,500.0,50.0), 

(300.0, 250.0,150.0,50.0)); 

I_WP : instance INTEGER; 

NUMBER.OBSTACLES, NUMBER_WAYPOINTS : instance INTEGER; 
INITIAL_X, INITIALLY, INITIAL_Z, INmAL_HEADING, 
FINAL_GOAL_X, FINAL_GOAL_Y : instance FLOAT; 

method CREATE (NEW_MISSION_MODEL: out OBJECT_ID) is 
begin 

NEW_MISSION_MODEL ;= instantiate; 
send (NEW_MISSION_MODEL, INITIALIZE); 
end CREATE; 

instance method INITIALIZE is 
begin 

I_WP := 0; — Index to keep track of current waypoint 
NUMBER_OBSTACLES := 4; 

NUMBER.WAYPOINTS := 12; 

INITIAL.X := 0.0; 
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INITIAL_Y := 0.0; 

INITIAL_Z ;= 0.0; 

INITIAL_HEAD1NG := 90.0; 

FINAL_GOAL_X := 250.0; 
nNAL_GOAL_Y := 150.0; 

PUT_LINEC‘Mission Model Created.”); 
end INITIALIZE; 

instance method GET_NUM_OBSTACLES (NUM_OBS : out INTEGER) is 
begin 

NUM_OBS := NUMBER_OBSTACLES; 
end GET_NUM_OBSTACLES; 

instance method GET_OBSTACLE (INDEX : in INTEGER; 

X_COORD : out FLOAT; Y_COORD : out FLOAT; 

Z_COORD : out FLOAT) is 
begin 

X_COORD := OBSTACLE_LIST(INDEX,l); 

Y_COORD := OBSTACLE_LIST(INDEX,2); 

Z_COORD := OBSTACLE_LIST(INDEX,3); 
end GET_OBSTACLE; 

instance method GET_INITIAL_STATE (IN1T_X; out FLOAT; 

INIT_Y : out FLOAT; INIT_Z: out FLOAT; 

INTT.HEADING : out FLOAT) is 

Hppin 

INfT_X ;= INITIAL_X; 

INIT_Y := INITIAL_Y; 

INIT_Z := INITIAL.Z; 

INIT_HEADING := INITIAL_HEADING; 
end GET_INITIAL_STATE; 

instance method GET_NUM_WAYPOINTS (NUM_WP : out INTEGER) is 
begin 

NUM^WP := NUMBER_WAYPOINTS; 
end GET_NUM_WAYPOINTS; 

instance method GET_WA YPOINT (INDEX: in INTEGER; 

SPEED ; out FLOAT; X_COORD : out FLOAT; 

Y_COORD : out FLOAT; Z_COORD ; out FLOAT) is 
begin 

SPEED :=WAYPOINT_LIST(INDEX,l); 

X_COORD := WAYPOINT_LIST(INDEX,2); 

Y_COORD := WAYPOINT_LIST(INDEX,3); 

Z_COORD := WAYPOINT_LIST(INDEX,4); 
end GET_WAYPOINT; 

instance method GET_FINAL_GOAL (X_FENAL : out FLOAT; 

Y_FINAL : out FLOAT) is 
begin 

X.FINAL := FINAL_GOAL_X; 
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Y_FINAL := FINAL_GOAL_Y; 
end GET_FINAL_GOAL; 

instance method GET_NEXT_WP (XWP: out FLOAT; YWP : out FLOAT) is 
begin 

I_WP;=I_WP+ 1; 

XWP ;= WAYPOINT_LIST(LWP,2); 

YWP := WAYPOINT_LIST(I_WP,3); 
end GET_NEXT_WP; 

instance method DELETE is 
begin 

PUT_LINE(“Mission Model Destroyed”); 

destroy; 

end DELETE; 

end MISSION.MODEL; 


— File: world_moclel_spec.ca 

— Author: Ron B. Byrnes 

— Date: 8 Oct 92 
System: Grus 

— Compiler: Classic Ada, VADS 

— Description: Contains the representation of the known world 

— relavent to the current mission 

class WORLD_MODEL is 

method CREATE (NEW_WORLD_MODEL: out OBJECT_ID); 
instance method INITIALIZE; 
instance method DELETE; 

end WORLD_MODEL; 
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— File: world_model_body.ca 

— Author; Ron B. Byrnes 

— Date: 8 Oct 92 
System: Grus 

— Compiler: Classic Ada, VADS 

— Description: 

with TEXTJO; 
use TEXTJO; 

class body WORLD_MODEL is 

method CREATE (NEW_WORLD_MODEL : out OBJECTJD) is 
begin 

NEW_WORLD_MODEL := instantiate; 
send (NEW_WORLD_MODEL, INITIALIZE); 
end CREATE; 

instance method INITIALIZE is 
begin 

PUT_LINE(“World Model being created,”); 
end INITIALIZE; 

instance method DELETE is 
begin 

PUT_LINE(“World Model being destroyed.”); 

destroy; 

end DELETE; 

end WORLD_MODEL; 
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— File: data_recorder_spec.ca 

— Author: Ron B. Byrnes 

— Date: 8 Oct 92 

— System: Grus 

-- Compiler: Classic Ada, VADS 

— Description: Accepts as input telemetry data for post-mission analysis 

— and messages indicating special circumstances (system faults, 

— replans). 

class DATA_RECORDER is 

method CREATE (NEW_DATA_RECORDER: out OBJECT_ID); 
instance method IMTIALIZE; 
instance method DELETE; 


end DATA_RECORDER; 


- File: data_recorder_body.ca 
-- Author: Ron B. Byrnes 

- Date: 8 Oct 92 

- System: Grus 

- Compiler: Classic_Ada, VADS 
'■ Description: 

with TEXTJO; 
use TEXTJO; 

class body DATA_RECORDER is 

method CREATE (NEW_DATA_RECORDER : out OBJECT_ID) is 
begin 

NEW_DATA_RECORDER := instantiate; 
send (NEW_DATA_RECORDER, INITIALIZE); 
end CREATE; 

instance method INITIALIZE is 
begin 

PUT_LINE(“Data Recorder created.”)^ 
end INITIALIZE; 

instance method DELETE is 
begin 

PUT_LINE(“Data Recorder destroyed,”)* 

destroy; 

end DELETE; 

end DATA_RECORDER; 
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— File: tactical5.ca 

— Author: Ron B. Byrnes 
-- Date: 2 Oct 92 

— Revised: 15 Dec 92 

— System: Grus 

— Compiler: Classic_Ada, VADS 

— Description: The program creates the AUV_OOD of the tactical level. Also provides 

— the communications link between the procedural and object-oriented worlds 

with TEXT JO, AUV^OOD, DATA_RECORDER, MISSION_MODEL, 
SENSORY_RECEIVER, WORLD_MODEL, C_L1B, CALENDAR; 
use TEXT JO, C.LIB, CALENDAR; 

procedure TACTICAL3 is 

OOD: OBJECT_ID := AUV_OOD.class_object; 

DR: OBJECTJD ;= DATA_RECORDER.class_object; 

MM : OBJECT_ID := MISSION_MODEL.class_object; 

SR : OBJECT JD := SENSORY_RECEIVER.class_object; 

WM : OBJECTJD ;= WORLD_MODEL.ciass_object; 


CODE: BOOLEAN; 

LOOP_COUNT: INTEGER := 0; 

BEGIN_TIME, END_TIME : TIME; 

TOT_SECS : DURATION; 
goal: INTEGER; 

GOAL_FLAG: INTEGER; 

STATUS^NUM: INTEGER; 

package FLOATJNOUT is new FLOATJO(FLOAT); 
useFLOAT_INOUT; 

package INTEGER_INOUT is new INTEGERJO(INTEGER); 
use INTEGER_INOUT; 

package FIXED JNOUT is new FIXED JO(DURATION); 
use FIXED JNOUT; 

procedure PRINT_HEADER is 
begin 

NEW_LINE; 

PUT_LINE(“Welcome to the startup program!”); 

NEW_LINE; 

endPRINT_HEADER; 

procedure PRINT_TRAILER is 
begin 

PUT_LINE(“Smiulation complete!”); 

NEW_LINE; 

end PRINT_TRA1LER; 

procedure INSTANTIATE_ALLES is 
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begin 

PUT_LINE(“Instantiations beginning from top level.,.”); 
send(DR, CREATE, new_data_recorder => DR); 
send(MM, CREATE, new_mission_model => MM); 
send(SR, CREATE, new_sensory_receiver => SR); 
send(WM, CREATE, new_world_model => WM); 
send(OOD, CREATE, new_auv_ood => OOD); 
send(OOD, NAV_OOD_BACKLINK, OOD => OOD); 
send(OOD, ENGR_OOD_BACKLINK, OOD => OOD); 
send(OOD, WEAP_OOD_BACKLINK, OOD => OOD); 
PUT_LINE(“Everything’s created!”); 

NFW 1 INF- 

end INSTANTIATE_ALLES; 

procedure DELETE_ALLES is 
begin 

PUT_LINE(“Deletions beginning from top level,..”); 

send (OOD, DELETE); 

send(DR, DELETE); 

send(MM, DELETE); 

send (SR, DELETE); 

send(WM, DELETE); 

PUT_LINjE(“Everything’s gone!”); 

NEW_LINE; 

end DELETE_ALLES; 

procedure LINKAGE JECTS is 
begin 

PUT_LINE(“Revealing handies of sub-objects...”); 
send(OOD, LINKUP_MM, pointer => MM); 
send(OOD, LINKUP_SR, pointer => SR); 
send(SR, LINKUP_DR, DR => DR); 
end LINK_OBJECTS; 

procedure OPEN_NETWORK is 
begin 

PUT(“Connecting tactical to execution now..,”); 
start_comms; 

NEW_LINE; 

PUT(“Staiting tactical server, listening for strategic level...”); 
start_iris_s; 

PUT_LINE(“Done!”); 
end OPEN_NETWORK; 

procedure READY_VEHICLE_FOR_LAUNCH is 
begin 

PUT_LINE(“Downloading mission parameters...”); 
PUT__LINE(“Obstacles first; x, y, and depth.”); 
send(OOD, DOWNLOAD_OBSTACLES); 
PUT_LINE(“Then the init state: x, y, depth, and heading.”); 
send(OOD, DOWNLOAD_INrnAL_STATE); 
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PUT_LINE(“Then the waypoints: speed, x, y, and depth.”); 
send(OOD, DO WNLOAD_W A YPOINTS); 

PUT_LINE(“Finally, the goal point: x_final and y_final.”); 
send(OOD, DOWNLOAD_FINAL_GOAL); 

PUT_LINE(“State loaded and systems checks completed.”); 

GOAL_FLAG := 1; *■ Should query OOD for success 
end READY_VEHICLE_FOR_LAUNCH; 

procedure SELECT_F1RST_WAYP01NT is 
begin 

PUT_LINE(“Selecting first waypoint, generating first “); 

PUT_LINEC‘ heading command, and sending it,”); 
send(OOD, SEL_1ST_WP); 

GOAL_FLAG := 1; 

NEWSLINE; 

PUT„LINE(“Mission initiated...”); 

NEW LINE- 

end SELECf_FIRsV_WAYPOINT; 

procedure ALERT_USER is 
begin 

NEW_LINE; 

PUT_LINE(“Failure occurred during mission download and/or “); 
PUT_LINE(“pre-mission checks. Please correct fault before “); 
PUT_LINEC‘proceeding.”); 

NEW_LINE; 

GOAL_FLAG := 1; 
end ALERT_USER; 

procedure IN_TRANSrr__P is 
begin 

GOAL_FLAG := 0; 
end IN_TRANSIT_P; 

procedure TRANSrr_DONE_P is 
begin 

GOAL.FLAG := 1; 
end TRANSIT_D0NE_P; 

procedure IN_SEARCH_P is 
begin 

GOAL_FLAG:=0; 
end IN_SEARCH_P; 

procedure SEARCH_DONE_P is 
begin 

GOAL_FLAG := 1; 
end SEARCH_DONE_P; 

procedure IN_TASK_P is 
begin 
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GOAL_FLAG := 0; 
end IN_TASK_P; 

procedure TASK_DONE_P is 
begin 

GOAL_FLAG := 1; 
end TASK_DONE_P; 

procedure IN_RETURN_P is 
begin 

GOAL^FLAG ;= 1; 
end IN_RETURN_P; 


procedure RETURN_DONE_P is 
begin 

send(OOD, REACH_GOAL, ans => CODE); 
if CODE then 
GOAL_FLAG ;= 1; 

NEW_LINE; 

PUT_LINE(“*************Goal Reached****************”^ 
NEWSLINE; ’ 

GOAL_FLAG ;= 0; 
end if; 

end RETURN_DONE_P; 

procedure WAIT_FOR_RECOVERY is 
begin 

GOAL^FLAG := 1; 

end WAIT_FOR_RECOVERY; 

procedure SURFACE is 
begin 

send(OOD, SURFACE); 

GOAL^FLAG := 1; 
end SURFACE; 

procedure DO_SEARCH_PATTERN is 
begin 

GOAL_FLAG:= 1; 

end DO_SEARCH_PATTERN; 

procedure HOMING is 
begin 

GOAL_FLAG := 1; 
end HOMING; 

procedure DROP_PACKAGE is 
begin 

GOAL_FLAG ;= 1; 
end DROP_PACKAGE; 
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procedure GET_GPS_FIX is 
begin 

GOAL_FLAG := 1; 
end GET_GPS_FIX; 

procedure GET_NEXT_WAYPOINT is 
begin 

send(OOD, GET_NEXT_WP); 

GOAL_FLAG := 1; 

end GET_NEXT_WAYPOINT; 

procedure SEND_WAYPOINTS_AND_MODES is 
begin 

send(OOD, EXECUTE^PLAN); 

GOAL_FLAG := 1; 

end SEND_WAYPOINTS_AND_MODES; 

procedure REACH_WAYPOINT is 
begin 

send(OOD, REACH_WAYPOINT, ans => CODE); 
if CODE then 
GOAL_FLAG := 1; 

PUT_LINE(“Waypoint obtained! Selecting next waypoint...”); 
get_time; 

GOAL_FLAG := 0; 
end if; 

send(OOD, GET_VEH_POSTURE); 

send(OOD, PLAN); 

end REACH_WAYPOINT; 

procedure GPS_NEEDED is 
begin 

GOAL_FLAG := 0; 
end GPS_NEEDED; 

procedure UNKNOWN_OBSTACLE_P is 
begin 

GOAL_FLAG := 0; 

end UNKNOWN_OBSTACLE_P; 

procedure LOG_NEW_OBSTACLE is 
begin 

GOAL_FLAG := 1; 

end LOG_NEW_OBSTACLE; 

procedure LOITER is 
begin 

GOAL_FLAG := 1; 
end LOITER; 
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procedure START_LOCAL_REPLANNER is 
begin 

GOAL_FLAG 1; 

end START_LOCAL_REPLANNER; 

procedure START_GLOBAL_REPLANNER is 
begin 

GOAL_FLAG := 1; 

end START_GL0BAL_REPLANNER; 

procedure POWER_GONE_P is 
begin 

send(OOD, POWER_CHECK, ans => STATUS_NUM); 
GOAL_FLAG ;= 0; 
end POWER_GONE_P; 


procedure COMPUTER_SYSTEM_PROB_P is 
begin 

GOAL_FLAG := 0; 

end COMPUTER_SYSTEM_PROB_P; 

procedure PROPULSION_SYSTEM^PROB_P is 
begin 

GOAL_FLAG := 0; 

end PROPULSION_SYSTEM_PROB_P; 

procedure STEERING_SYSTEM_PROB_P is 
begin 

GOAL_FLAG := 0; 

end STEERING_SYSTEM_PROB_P; 

procedure DlVING_SYSTEM_PROB_P is 
begin 

GOAL.FLAG := 0; 

end DIVING_SYSTEM_PROB_P; 

procedure BOUYANCY_SYSTEM_PROB_P is 
begin 

GOAL_FLAG := 0; 

end BOUYANCY_SYSTEM_PROB„P; 

procedure THRUSTER_SYSTEM_PROB_P is 
begin 

GOAL_FLAG := 0; 

end THRUSTER_SYSTEM_PROB_P; 

procedure LEAK_TEST_P is 
begin 

GOAL_FLAG := 0; 
end LEAK_TEST_P; 
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procedure PAYLOAD_PROB_P is 
begin 

GOAL_FLAG := 0; 
end PAYLOAD_PROB_P; 


procedure CLOSE_NETWORK is 
begin 

PUT_LINE(“Closing tactical/execution network.,.”); 
stop_comms; 

PUT_LINE(“Closing down tactical level server...”); 
stop_iris_s; 

end CLOSE_NETWORK; 

procediue PRINT_PROFILE is 
begin 

TOT_SECS := SECONDS (END-TIME) - SECONDS (BEGIN_TIME); 
NEW_LINE; 

PUT(“For the mission, the total execution time was; “); 
PUT(TOT_SECS); 

NEWSLINE; 

PUT(“and the total control cycles taken was; “); 

PUT(LOOP_COUNT); 

NEW_LINE; 

P0T(“Yielding a control rate of “); 
PUT(FLOAT(LOOP_COUNT)/FLOAT(TOT_SECS)); 

PUT(“ commands per second.”); 

NEW_LINE; 

end PRINT_PROFILE; 


begin 

PRINT_HEADER; 

INSTANnATE_ALLES; 

LINK_OBJECTS; 

OPEN_NETWORK; 
goal := get_firom_strat_i; 

loop 

— PUT_LINE(“Primitive goal received. Initiating behavior...”); 
LOOP_COUNT ;= LOOP.COUNT + 1; 
case goal is 

when 10 => READY_VEHICLE_FOR_LAUNCH; 
put_iiis_i_s(GOAL_FLAG); -- Download mission, etc, 
when 11 => SELECT_FIRST_WAYPOINT; 
BEGIN_TIME := CLOCK; - Start mission timer 
get_time; 

put_iris_i_s(GOAL_FLAG); 
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when 12 => ALERT_USER; 
put_iris_i_s (GO AL_FL AG); 
exit; 

when 13 => IN_TRANSIT_P; 

put_ms_i_s(GOAL_FLAG); -- send(OOD, in_transit_p) 
when 14=>TRANSIT_DONE_P; 

put_irisJ_s(GOAL_FLAG); - send(OOD, transit_done_p) 
when 15 => IN_SEARCH_P; 

put_iris_i_s(GOAL_FLAG); — send(OOD, in_search_p) 
when 16 => SEARCH_DONE_P; 

put_iris_Ls(GOAL_FLAG); - send(OOD, search_done_p) 
when 17 => IN_TASK_P; 

put_iris_i_s(GOAL_FLAG); - send(OOD, in_task_p) 
when 18 => TASK_DONE_P; 

put_irisJ_s(GOAL_FLAG); - send(OOD, task_done_p) 
when 19 => IN_RETURN_P; 

put_iris_i_s(GOAL_FLAG); — send(OOD, in_retum_p) 
when 20 => RETURN_DONE_P; 

put_ms_i_s(GOAL_FLAG); -- send(OOD, return_done_p) 
when 21 => WAIT_FOR_RECOVERY; 
put_iris_i_s(GOAL_FLAG); -- send(OOD, wait_for_recovery) 
cxit^ 

when 22 => SURFACE; 

put_iris_i_s(GOAL_FLAG); — send(OOD, surface) 
when 23 => DO_SEARCH_PATTERN; 
put_iris_i_s(GOAL_FLAG); - send(OOD, do_search_pattem) 
when 24 => FiOMING; 

put_iris_i_s(GOAL_FLAG); -- send(OOD, homing) 
when 25 => DROP.PACKAGE; 

put_iris_i_s(GOAL_FLAG); - send(OOD, drop_package) 
when 26 => GET_GPS_FIX; 

put_ms_i_s(GOAL_FLAG); -- send(OOD, get_gps_fix) 
when 27 => GET_NEXT_WAYPOINT; 
put_iris_i_s(GOAL_FLAG); -- send(OOD, get_next_waypoint) 
when 28 => SEND_WAYPOINTS_AND_MODES; 
put_iris_i_s(GOAL_FLAG); -- send(OOD, send_waypoints_and„modes) 
when 29 => REACH.WAYPOINT; 
puUiris_i_s(GOAL_FLAG); -- send(OOD, reach_waypoint) 
when 30 => GPS_NEEDED; 

put_iris_i_s(GOAL_FLAG); — send(OOD, gps_needed) 
when 31 => UNKNOWN_OBSTACLE_P; 
put_iris_i_s(GOAL_FLAG); - send(OOD, unknown_obstacle_p) 
when 32 => LOG_NEW_OBSTACLE; 
put_ms_i_s(GOAL_FLAG); -- send(OOD, log_new_obstacle) 
when 33 => LOITER; 

put_iris_i_s(GOAL_FLAG); -- send(OOD, loiter) 
when 34 => START_L0CAL_REPLAN1S[ER; 
put_iris_i_s(GOAL_FLAG); -- send(OOD, start_locai_replanner) 
when 35 => START_GLOBAL_REPLANNER; 
put_iris_i_s(GOAL_FLAG); -- send(OOD, start_global_replanner) 
when 36 => POWER_GONE_P; 
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put_iris_i_s(GOAL_FLAG); — send(OOD, power_gone_p) 
when 37 => COMPUTER_SYSTEM_PROB_P; 
put_iris_i_s(GOAL_FLAG); — send(OOD, computer_system_prob_p) 
when 38 => PROPULSION_SYSTEM_PROB_P; 
put_iris_i_s(GOAL_FLAG); — send(OOD, propulsion_system_prob_p) 
when 39 => STEERING__SYSTEM_PROB_P; 
put_iris_i_s(GOAL_FLAG); — send(OOD, steering_systeni_prob_p) 
when 40 => DIVING_SYSTEM_PROB_P; 
put_iris_i_s(GOAL_FLAG); - send(OOD, diving_system_prob_p) 
when 41 => BOUYANCY_SYSTEM_PROB_P; 
put_iris_i_s(GOAL_FLAG); -- send(OOD, bouyancy_systeni_prob_p) 
when 42 => THRUSTER_SYSTEM_PROB_P: 
put_ms_i_s(GOAL_FLAG); — send(OOD, thruster_system_prob_p) 
when 43 => LEAK_TEST_P; 

put_iris_i_s(GOAL_FLAG); - send(OOD, leak_test_p) 
when 44 => PAYLOAD_PROB_P; 
put_iris_i_s(GOAL_FLAG); - send(OOD, payload_prob_p) 
when others => PUT(“Unexpecled goal value received: “); 

PUT(goal); 

NEW_LINE; 

end case; 

goal := get_from_straui; 

end loop; 

END_TIME ;= CLOCK; 

get_tinie; 

CLOSE_NETWORK; 

DELETE_ALLES; 

PRINT_TRAILER; 

PRINT_PROFILE; 

end TACTICALS; 
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APPENDIX C. INTER-LEVEL COMMUNICATIONS SOFTWARE 


1. PROLOG-TO-ADA, PROLOG SIDE 


/* This is the Prolog-to-C “glue” software 
Date created: 30 Nov 92 
Date Revised; 9 Dec 92 


To be run on any workstation. NOTE: to obtain an object file xxx.o, invoke the compiler 
as follows: 

cc -c xxx.c 

where xxx is the file name. The -Im flag must be placed after the name of the source file if 
linkage to the math.h library is desired, */ 

#include <stdio.h> 

#include <time.h> 

ready_vehicle_for_launch_p() /* Perform systems status check and download 
mission parameters. Integers passed to Tactical level represent primitive goals. */ 

int result; 

printf(“%s\n”, “Entered the function ready_vehicle_for_launch_p”); 

start_link(); 

put_iris_i(10); 

printf(“Vi”); 

get_iris_i(<^esult); 

return (result); 

} 

select_first_waypoint() 

{ 

int result; 

printf(“%sSn”, “Entered the function select_first_waypoint”); 

put_iris_i(l 1); 

printf(“\n”); 

get_iris_i(&result); 

return (result); 

} 
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alert_user() 

{ 

int result; 

printf(“%s\n”, “Entered the function alert_user”); 

put_iris_i(12); 

printf(“\n”); 

get_iris_i(&result); 

return (result); 


in_transit_p() { 
int result; 

printf(“%s\n”, “Entered the function in_transit_p”); 

put_iris_i(13); 

printfCV”); 

get_iris_i(jSn-esult); 

return (result); 


transit_done_p() { 
int result; 

printf(“%s\n”, “Entered the function transit_done_p”); 

put_iris_i(14); 

printf(“\n”); 

get_iris_i(&esult); 

return (result); 


in_search_p() { 
int result; 

printf(“%s\n”, “Entered the function in_search_p”); 

put_iris_i(15); 

printf(“\n”); 

get_iris_i(&result); 

return (result); 


search_done_p() { 
int result; 

printf(“%s\n”, “Entered the function search_done p”); 

put_iris_i(16); 

printf(“Nn”); 

get_irisj(<foesult); 

return (result); 
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in_task_p() { 

int result; 

printf(“%s\n”, “Entered the function in_task_p”); 

put_iris_i(17); 

printf(‘^n”); 

get_ms_i(&result); 

return (result); 


task_done_p() { 
int result; 

printf(“%s\n”, “Entered the function task_done_p”); 
put_iris_i(18); 

printfCV”); 

get_iris_i(&result); 
return (result); 


in_retum_p() { 
int result; 

printf(“%s\n”, “Entered the function in_retum_p”); 

put_iris_i(19); 

printf(“\n”); 

get_iris_i(&xesult); 

return (result); 


retum_done_p() { 
int result; 

printf(“%sNn”, “Entered the function retum_done_p”); 

put_iris_i(20); 

printfCV”); 

get_iris_i((Sb'esuit); 

return (result); 


wait_for_recovery() { 
int result; 

printf(“%s\n”, “Entered the function wait_for_recovery”); 

put_iris_i(21); 

printfC^n”); 

get_iris_i(&Tesult); 

/* Delay may be needed to insure server has time to shut down */ 

stop_liiik(); 

return (result); 
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surfaceQ { 

int result; 


printf(“%s\n”, “Entered the function surface”); 

put_iris_i(22); 

printfC^n”); 

get_iris_i(&esult); 

return (result); 


do_search_pattem() { 
int result; 

printf(“%s\n”, “Entered the function do_search_pattern”); 

put_iris_i(23); 

printf(“\n”); 

get_iris_i(<^esult); 

return (result); 


homingO { 

int result; 


printf(“%s\n”, “Entered the function homing”); 

put_iris_i(24); 

printf(“Vn”); 

get_iris_i(&result); 

return (result); 


drop_package() { 
int result; 


printf(“%s\n”, “Entered the function drop_package”); 

put_iris_i(25); 

printf(‘V”); 

get_iris_i(<Sn'esult); 

return (result); 


get_gps_fix() { 
int result; 


printf(“%s\n”, “Entered the function get_gps_fix”); 

put_iris_i(26); 

printf(“\n”); 

get_iris_i(<l^esult); 

return (result); 
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get_next_waypoint() { 
int result; 


printf(“%s\n”, “***Waypoint attained***”); 

printf(“%s\n”, “Entered the function get_next_waypoint”); 

put_iris_i(27); 

printf(“Sn”); 

get_iris_i(&result); 

return (result); 


send_setpoints_and_modes() { 
int result; 

printf(“%s\n”, “Entered the function send_setpoints_and_modes”); 

put_iris_i(28); 

printfCV”); 

get_iris_i(&result); 

return (result); 


reach_waypomt_p() { 
int result; 

printf(“%s\n”, “Entered the function reach_waypoint_p”); 

put_iris_i(29); 

printfC^n”); 

get_iris_i(&esult); 

return (result); 


gps_needed_p() { 
int result; 

printf(“%s\n”, “Entered the function gps_needed_p”); 

put_iris_i(30); 

printfC^n”); 

get_iris_i(<feesult); 

return (result); 


unknown_obstacle_p() { 
int result; 

printf(“%sNn”, “Entered the function unknown_obstacle_p”); 

put_iris_i(31); 

printfC^n”); 

get_iris_i(«5iresult); 

return (result); 
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log_new_obstacle() { 
int result; 


printf(“%s\n”, “Entered the function log_new_obstacle”); 

put_iris_i(32); 

printf(“Vi”); 

get_iris_i((^esult); 

return (result); 


loiterO { 

int result; 

printf(“%s\n”, “Entered the function loiter”); 

put_iris_i(33); 

printf(“\n”); 

get__iris_i(&result); 

return (result); 


start_locai_replanner() { 
int result; 

printf(“%s\n”, “Entered the function start_local_replanner”); 

put_iris_i(34); 

printf(“\n”); 

get_irisj(&result); 

return (result); 


start_global_replanner() { 
int result; 

printf(“%s\n”, “Entered the function start_global_replanner”); 

put_iris_i(35); 

printf(“\n”); 

get_iris_i(&result); 

return (result); 


power_gone_p() { 
int result; 


printf(“%s\n”, “Entered the function powereone p”); 

put_iris_i(36); 

printf(“\n”); 

get_iris_i(toesult); 

return (result); 


computer_system_inop_p() { 
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int result; 


printf(“%s\n”, “Entered the function computer_systein_inop_p”); 

put_ms_i(37); 

printf(‘^n”); 

get_iris_i(&result); 

return (result); 


propulsion_system_p() { 
int result; 

printf(“%sNn”, “Entered the function propulsion_systeni_p”); 

put_iris_i(38); 

printf(“\n”); 

get_iris_i(<foesult); 

return (result); 


steering_system_inop_p() { 
int result; 

printf(“%s\n”, “Entered the function steering_system_inop_p”); 

put_iris_i(39); 

printf(“\n“); 

get_iris_i(&Tesuit); 

return (result); 


diving_system_p() { 
int result; 

printf(“%s\n”, “Entered the function diving_system_p”); 

put_iris_i(40); 

printf(‘V”); 

get_iris_i(&result); 

return (result); 


bouyancy_system_p() { 
int result; 

printf(“%sNn”, “Entered the function bouyancy_system_p”); 

put_iris_i(41); 

printfCV”); 

get_iris_i(<&xesult); 

return (result); 


thruster_system_p() { 
int result; 
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printf(“%s\n”, “Entered the function thruster_system_p”); 

put_iris_i(42); 

printfCV”); 

get_iris_i(&result); 

return (result); 


leak_test_p() { 
int result; 

printf(“%s\n“, “Entered the function leak_test_p”); 

put_iris_i(43); 

printf{‘^n”); 

get_iris_i(&result); 

return (result); 


payload_prob_p() { 
int result; 

printf(“%s\n”, “Entered the function payload_prob_p”); 

put_iris_i(44); 

printf(“\n”); 

get_iris_i(&esult); 

return (result); 

} 


get_time() 

{ 

time_t now; 
now = time(NULL); 

printf(“%s%s\n”, “ The time is now = ctime(&now)); 


y*******!f!***!i!*jf!********!(s* communications software ********************y 


start_link() 

{ 

start_iris(“gemini”); /* hardwire tactical level host (server) specified here */ 
retum(99); 

} 

stop_link() 

{ 

stop_iris(); 

retum(lOO); 
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} 


/**$$***************************************************************/ 


^******5(!**Sf!****!t:5i!!*:if!**!|S**!(!*****Sf:* + **J(e*****!(<*******!f!*j(c*****!(!!i!****5f: + !(C**%** 


Filename.; clienLc 

This program creates a socket and returns the socket. 
The following function is available. 

1. Created by Sehung Kwak 10/10/90 


usage: connect_to_server(remote_server_host_name, port_number) 
; returns a socket 


3k * ^ 3|c % 4: * ^ >i: 3|cIk 4= ij: * He ^ ^ ^ ^ Hi ^ ^ ^ ^ * :f: * %^ ^:k ik 4: * * 4c^ 9f: 

#include <sys/types.h> 

#include <sys/sockeLh> 

#include <netine^in.h> 

#include <netdb.h> 

#include <stdio.h> 


/* 

Return socket 
*/ 

connect_to_server(remote_server_host_name, port_number) 

char *remote_server_host_name; 
int port_number; 


int sock; 

struct sockaddrjn server; 

struct hostent *hp, *gethostbyname(); 

char buf[1024]; 

sock = socket(AF_INET, SOCK_STREAM, 0); 
if (sock < 0) { 

perror(“opening stream socket”); 
exit(l); 

} 

server.sin_family = AF_INET; 

hp = gethostbyname(remote_server_host_name); 

if(hp = 0){ 

^)rintf(stderr, “%s: unknown hosiNn”, remote_server_host_name); 
exit(2); 

} 
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bcopy((char *)hp->h_addr, (char *)&server.sin_addr, hp->h_length); 
server. sin_port = htons(port_number); 

if (connect(sock, (struct sockaddr *)&server, sizeof server) < 0) { 

perror(“connecting stream socket”); 

exit(l); 

} else 

retum(sock); 

} 


/ 


Filename.: comm_gluelc.c 

This takes care of socket stream communication interface. 
Following functions are available, 

A Sun running this program should be client, 

1. Created by Sehung Kwak 10/10/90 

2. Modified for C language interface, Sehung Kwak 1/27/92 


usage ; open_stream_c (host_name port_number); open stream 

write string c (string); write string 

read_string_c (string, size); read string 

write_char_c (length_one_string); write character 

force_out_c (); output write buffer 

Tead_char_c Q ; read character 

close_stream_c (); close stream 


This file needs clientc. 

****iit*!fC!i!***ii!**>l!***!(«=f!!(«!(«*******************if:******!(«!(!*Sf!**S|S5(!***S|t!jt!(i!i<**!i'*!t!*5(!/ 


#define TRUE 1 
#define FALSE 0 
#define BUFSIZE 1024 


static int sock; 

static char sbuf[BUFSIZE]; 

static int sptr = 0; 

open_stream_c (host_name, port_num) 
char host_name[]; 
long port_num; 

{ 

sock = connect_to_server(host„name,(int) port_num); 

bzero(sbuf, sizeof sbuf); /* initialize send buffer */ 
sptr = 0; /* initialize send buffer pointer */ 

if (sock >= 0) 
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retuin(TRUE); 

else 

retum(FALSE); 

} 

write_string_c (ps) 
char *ps; 

{ 

if (write(sock, ps, strlen(ps)) < 0) { 
perror(“Writing on stream socket”); 
retum(FALSE); 

} else 

retum(TRUE); 

} 

force_out_c () 

{ 

if (write_string_c(sbuf) == TRUE) { 
bzero(sbuf, sizeof sbuf); 
sptr = 0; 
retum(TRUE); 

} else 

retum(FALSE); 

} 


write_char_c (ps) 
char *ps; 

{ 

sbuf[sptr++]=*ps; 

if(sptr==BUFSIZE) 

force_out_c(); 

} 

read_string_c (str, size) 
char str[]; 
int size; 

{ 

if (read(sock, str, size) < 0) { 
perror(“Reading stream socket”); 
retum(FALSE); 

} else 

retum(TRUE); 

} 

char *read_char_c () 

{ 

char onestr[4]; 
bzero(onestr, sizeof onestr); 
if (read(sock, onestr, 1) < 0) { 
perror(“Reading stream socket”); 
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retum(‘\D’); 

} else 

retum(onestr); 


close_stream_c() 

{ 

if (close(sock) < 0) 

retum(FALSE); 

else 

retum(TRUE); 


^ % a(e )(s)): sfc ^ sfs ^He ^ ^ ^ ^ ^ ^ 4: ^ ^ 4: sk ^ ^ 4s :jc af; ^ ^ Iff ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 


Filename.: convert.c 

This program converts a number (float or integer) or a string 
to a communiction format and also records received data to 
a number(float or integer) or a string. 

Communication Format 

TXXXXDDDDDDDD.... 

T: type (one of I, R, C. i.e., integer, float, string) 

XXXX : data size in byte, filled with leading zeros 
DDD...: actual data (sequence of ASCII characters) 

example: 10003123 

AAAAAAAA 

TXXXXDDD 


1. Created by Sehung Kwak 1/27/92 

usage: float_to_data(float, data); float -> data 
integer_to_data(integer, data); integer —> data 
string_to_data(string,data); string --> data 
data_to_float(data,float*); data --> float 
data„to_integer(data,integer*); data —> integer 
data_to_string(data,string); data -> string 


4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4^ 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c j 


#include <stdio.h>; 
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#define MAX_FLOAT_SIZE 30 
#define MAX_INTEGER_SIZE 30 


void float_to_data(x, data) 
float x; 
char data[]; 

{ 

char x_str[MAX_FLOAT_SIZE]; 
sprmtf(x_str, “%fx); 

sprintf(data, “R%04d%s”, strlen(x_str), x_str); 

} 


void integer_to_data(x, data) 
intx; 

char data[]; 

{ 

char x_str[MAX_INTEGER_SIZE]; 

sprintf(x_str, “%d”, x); 

sprintf(data, “I%04d%s”, strlen(x_str), x_str); 

} 


void string_to_data(str, data) 
char str[], data[]; 

{ 

sprintf(data, “C%04d%s”, strlen(str), str); 

} 


void data_to_float(data, px) 
char dataQ; 
float* px; 

{ 

char type; 
iitt size; 

sscanf(data,”%lc%4d%f&type, &size, px); 


void data_to_integer(data, px) 
char dataQ; 
int* px; 

{ 

char type; 
int size; 

sscanf(data,”%lc%4d%d”, &type, &size, px); 
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} 


void data_to_string(data, str) 
char data[], strQ; 

{ 

char type; 
int size; 

sscanf(data, “%lc%4d%s”, &type, &size, str); 


/ 

; Filename.: sun_iris_commslc.c 

; 1. Created by Sehung Kwak 1/27/92 
; Use one socket for communication. 

; *local-port* 1053 


usage : start_iris (“<target server ID>”); make connection 

put_iris_s (string); send string data 

put_iris_f (float); send floating point number 

put_iris_i (integer); send integer number 

get_iris_s (string); get string data 

get_iris_f (&float); get float data (ptr) 

get_iris_i (&integer); get integer data (ptr) 

stop_iris(); close communication 


This file needs convertx and comm_gluelc.c 

9|c djc djc 9^ 9^ 9|( 9{C 9jc 9|c 9^ 9jc 9^ 9^ 9^ 9^ 9fC 9^ 9^ 9^ 9|C 9^9|C 9^ 9^ 9^ 9^ 9^9^ 9^ 9^ 9(9 9(C 9(( 9(C 9(C 9|C 9(9 9(9 9(C 9(( 9(C j 


#include <stdio.h>; 

#define TRUE 1 
#define FALSE 0 
#define LOCAL.PORT 1051 
#defme STR_BUFSIZE 1024 
#defme NUM_BUFSIZE 30 

start_iris(host_name) 
char host_name[]; 

{ 

if (open_stream_c(host_name,LOCAL_PORT)) 

retum(TRUE); 

else 
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} 


retum(FALSE); 


stop_iris() 

{ 

retum(close_stream_c()); 

} 


put_iris_s(sir) 
char str[]; 

{ 

char buf[STR_BUFSIZE]; 

string_to_data(str,buf); 

write_string_c(buf); 

force_out_c(); 

retum(TRUE); 

} 


put_iiis_f(num_f) 
float num„f; 

{ 

char buf[NUM_BUFSIZE]; 

float_to_data(num_f, buf); 
write_string__c(buf); 
force_out_c(); 
retiim(TRUE); 

} 

put_iris_i(num_i) 
int num_i; 

{ 

char buf[NUM_BUFSIZE]; 

bzero(buf, sizeof buf); 
integer_to_data(num_i, buf); 
printf(“Int to data is %s\n”, buf); 

write_string_c(buf); 

retum(TRUE); 

} 


get_iris_s(str) 
char *str; 

{ 

char buf[STR_BUFSIZE]; 
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read_string_c(buf,STR_BUFSIZE); 
data_to_string(buf^, str); 
retum(TRUE); 


get_iiis_f(pf) 
float *pf; 

{ 

char buf[NUM_BUFSIZE]; 

read_string_c(buf,NUM_BUFSIZE); 
data_to_float(buf, pf); 
retizm(TRUE); 

} 

getjris_i(pi) 
int *pi; 

{ 

char buf[NUM_BUFSIZE]; 

bzero(buf, sizeof buf); 
read_string_c( buf,NUM_BUFSIZE); 
data_to_integer(buf, pi); 
retum(TRUE); 

) 


/ 


259 








2. PROLOG-TO-ADA, ADA SIDE 


package C_LIB is 

— CLIENT comms, supporting Tactical<->Execution level 

procedure start_comms; — make connection to E-level 
procedure put_float (X : FLOAT); - send float to E-level 
function get_float return FLOAT; - receive float from E-level 
procedure put_mode (X : INTEGER); — send mode to E-level 
procedure stop_comms; — close connection to E-level 

— SERVER comms, supporting Strategic<->Taclical level 

procedure start_iris_s; — establish term as server 
procedure put_iris_Ls (X : INTEGER); - send int to S-level 
function get_from_strat_i return INTEGER;- receive int from S-level 
procedure stop_iris_s; 

— System clock access function. Better than Ada’s 
procedure get_time; 

private 

pragma ENTERFACE(C, start_comms); 
pragma INTERFACE(C, put_fIoat); 
pragma INTERFACE(C, get_float); 
pragma INTERFACE(C, stop_comms); 
pragma INTERFACE(C, put_mode); 
pragma INTERFACE(C, start_iris_s); 
pragma INTERFACE(C, put_iris_i_s); 
pragma INTERFACE(C, get_from_strat_i); 
pragma INTERFACE(C, stop_iris_s); 
pragma INTERFACE(C, get_time); 


pragma LINK_WITH(“network_sw.o”); — lump all above files together 
end C_LIB; 


/* Network comms for the Tactical level. The Tactical level must act 
as a server for the Strategic level and a client for the Execution 
level. Code with a filename ending in “s” is server code; those 
files ending in “c” are client code. 
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Date: 12 Jan 93 
*/ 


#include <sy s/types. h> 
#include <sys/socket.h> 
#include <netinet/in.h> 
#include <netdb.h> 
#include <stdio.h> 

#mclude <string.h> 

#include <time.h> 


/* server.c, clientc */ 

/* server.c, clientc */ 

/* server.c, client.c */ 

/* server.c, client.c */ 

/* server.c, convert.c, sun_iris_commsls.c, ciientc, 
sun_iris_commslc.c */ 

!* sun_iris_commslc.c */ 


#define TRUE 1 
^define FALSE 0 
#define BUFSIZE 1024 


/* comm_glue_ls.c, sun_iris_commsls.c, 
comm_glue_lc,c, sun_iris_commslc.c */ 
/* comm_glue_ls.c, sun_iris_commsls.c, 
comm_glue_lc.c, sun_iris_commslc.c */ 
/* conim_glue_ls.c, comm_glue_lc.c */ 


#defme MAX_FLOAT_SIZE 30 
#define MAXJNTEGER_SIZE 30 
#defme STR_BUFSIZE 1024 
#define NUM_BUFSIZE 30 
#define GET_DATA “get_data” 
#define ST_LOCAL_PORT 1051 
#define TE_LOCAL_PORT 1052 


/* convert.c */ 

/* convert.c */ 

/* sun_iris_conimsls.c, sun_iris_commslc.c 
/* sun_iris_conimsls.c, sun_iris_commslc.c 
/* sun_iris_cominsls.c, sun_jris_conmislc.c 
/* sun_iris_commsls.c */ 

/* sun_iris_commslc.c */ 


*1 

*/ 


static int sock;_s, sock_c; 
static char sbuf_s[BUFSIZE]; 
static char sbuf_c[BUFSIZE]; 
static int sptr_s = 0; 
static int sptr_c = 0; 


/* comm_glue_ls.c, cortim_glue_lc.c */ 

/* comm_glue_ls,c, comm_glue_lc.c */ 
/* comm_glue_ls.c, corrtm_glue_lc.c */ 




Filename.: client.c 

This program creates a socket and returns the socket. 
The following function is available. 

1. Created by Sehung Kwak 10/10/90 


usage: connect_to_server(remote_server_host_name, port_number) 
; returns a socket 


.***♦*♦*♦*************************************************************/ 


f* 

Return socket 
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*! 

connect_to_server(remote_server_host_name, port_number) 

char *remote_server_host_name; 
int port_number; 


int sock; 

struct sockaddr_in server; 

struct hostent *hp, *gethostbyname(); 

char buf[1024]; 

sock = socket(AF_INET, SOCK_STREAM, 0); 
if (sock < 0) { 

perror{“opening stream socket”); 
exit(l); 

} 

server. sin_faniily = AF_INET; 

hp = gethostbyname(remote_server_host name); 

if (hp = 0) { 

fprintf(stdeiT, “%s: unknown host\n”, remote server host name): 
exit(2); - - _ y, 

} 

bcopy((char *)hp->h_addr, (char *)&server.sin_addr, hp->hjength); 
server.sin_port = htons(port_number); 

if (connect(sock, 

(struct sockaddr *)&server, sizeof server) < 0) { 
perror(“connecting stream socket”); 
exit(l); 

) else 

retum(sock); 


1 

; Filename.; server.c 

> 

; This program creates a socket and returns the socket. 
; The following function is available. 

» 

; 1, Created by Sehung Kwak 12/3/91 


usage; stait_server(port_number) 
; returns a socket 
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!j|£!(<**j(c*!|e******!|£***!f!********!(<Nt***********=i'*****************************/ 


/* 

Returns socket 

*! 

int start_server(port_number) 

int port_number; /* server port number */ 

{ 

int sock; 

struct sockaddr_in server; 
int msgsock; 

sock = socket(AF_INET, SOCK_STREAM, 0); 
if (sock < 0) { 

perror(“opening stream socket”); 
exit(l); 

} 

server. sin_family = AF_INET; 
server.sin_addr,s_addr = INADDR_ANY; 
server.sin_port = port_number; 
if (bind(sock, (struct sockaddr *)&server, 
sizeof server) < 0) { 
perror(“binding stream socket”); 
exit(l); 

} 

listen(sock,5); 

msgsock = accept(sock, (struct sockaddr *)0, (int *)0); 

if (msgsock ==-l) { 

peiTor(“accept”); 

exit(2); 

} else 

retum(msgsock); 

} 


J(C*********************************************************************** 

; Filename.: comm_gluelc.c 

; This takes care of socket stream communication interface. 

; Following functions are available. 

; A Sun running this program should be client. 

; 1. Created by Sehung Kwak 10/10/90 
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; 2. Modified for C language interface, Sehung Kwak 1/27/92 


usage : open_stream_c (host_name port_number); open stream 

write_string_c (string); write string 

read_string_c (string, size); read string 

write_char_c (length_one_string); write character 

force_out_c (); output write buffer 

read_char_c (); read character 

close_stream_c (); close stream 


This file needs clientx. 




open_stream_c (host_name, port_num) 
char host_name[]; 
long port_num; 

{ 

sock_c = connect_to_server(host_name,(int) port_num); 

bzero(sbuf_c, sizeof sbuf_c); /* initialize send buffer */ 
sptr„c = 0; /* initialize send buffer pointer */ 

if (sock_c >= 0) 

retum(TRUE); 

else 

retum(FALSE); 

} 

wrile_string_c (ps) 
char *ps; 

{ 

if (write(sock_c, ps, strlen(ps)) < 0) { 
perror(“Writing on stream socket”); 
retum(FALSE); 

} else 

retum(TRUE); 

} 


force_out_c () 

{ 

if (write_string_c(sbuf_c) == TRUE) { 
bzeTo(sbuf_c, sizeof sbuf_c); 
sptr_c = 0; 
retum(TRUE); 

} else 

retum(FALSE); 

} 
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write_char_c (ps) 
char *ps; 

{ 

sbuf_c [sptr_c++]=*ps; 

if(sptr_c==BUFSIZE) 

force_out_c(); 

} 


read_string_c (str, size) 
char strO; 
int size; 

{ 

if (read(sock_c, str, size) < 0) { 
perror(“Reading stream socket”); 
retum(FALSE); 

} else 

retum(TRUE); 

} 

char *read_char_c () 

{ 

char onestr[4]; 
bzero(onestr, sizeof onestr); 
if (read(sock_c, onestr, 1) < 0) { 
perror(“Reading stream socket”); 
retum(‘M)’); 

} else 

retum(onestr); 

} 


close_stream_c() 

{ 

if (close(sock_c) < 0) 

retum(FALSE); 

else 

retum(TRUE); 

} 


/ 

^ 4:3k 4c 3 (e jfe # 4: ^ 3fe % 3je 3fi 4: ^ sfE 4e 3fc a(s :je ^ ^ 3k 4c jife 4:3k % 3f: :)e afe 9)e ^ ak 4:^ ^ :(£ :{c :{e :fc ifs :|e 

> 

; Filename.: comm_gluels.c 

y 

; This takes care of socket stream communication interface. 

; Following functions are available. 
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; A Sun running this program should be server. 
; 1. Created by Sehung Kwak 12/3/92 


usage : open_stream_s (port_number); open write stream 

write_string_s (string); write string 

read_string_s (string, size); read string 

write_char_s (length_one_string); write character 

force_out_s (); output write buffer 

read_char_s Q ; read character 

close_stream_s (); close stream 


This file needs server.c. 




open_stream_s (port_num) 
long port_num; 

{ 

sock_s = start_server((int) port_num); 

bzero(sbuf_s, sizeof sbuf_s); t* initialize send buffer */ 
sptr_s = 0; /* initialize send buffer pointer */ 

if (sock_s >= 0) 

retum(TRUE); 

else 

retum(FALSE); 

} 


write_string_s (ps) 
char *ps; 

{ 

if (write(sock_s, ps, strlen(ps)) < 0) { 
perror(“Writing on stream socket”); 
retum(FALSE); 

} else 

retum(TRUE); 

) 


force_out_s () 

{ 

if (wnte_stiing_s(sbuf_s) = TRUE) { 
bzero(sbuf_s, sizeof sbuf_s); 
sptr_s = 0; 
retum(TRUE); 

) else 
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} 


retum(FALSE); 


write_char_s (ps) 
char *ps; 

{ 


sbuf_s[sptr_s++]= *ps; 

if(sptr_s==BUFSIZE) 

force_out„s(); 


} 


read_string_s (str, size) 
char strQ; 
int size; 

{ 

if (read(sock_s, str, size) < 0) { 
perror(“Reading stream socket”); 
retum(FALSE); 

} else 

retiim(TRUE); 

} 

char *read_char_s () 

{ 

char onestr[4]; 
bzero(onestr, sizeof onestr); 
if (read(sock_s, onestr, 1) < 0) { 
perror(“Reading stream socket”); 

retumC'NO’); 

} else 

retum(onestr); 

} 


close_stream_s() 

{ 

if (close(sock_s) < 0) 

retum(FALSE); 

else 

retum(TRUE); 

} 


; Filename.: conveit.c 
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This program converts a number (float or integer) or a string 
to a communiction format and also records received data to 
a number (float or integer) or a string. 

Communication Format 

TXXXXDDDDDDDD,... 

T : type (one of I, R, C. i.e., integer, float, string) 

XXXX : data size in byte, filled with leading zeros 
DDD...: actual data (sequence of ASCII characters) 

example: 10003123 

AAAAAAAA 

TXXXXDDD 


1, Created by Sehung Kwak 1/27/92 

usage: float_to_data(float, data); float --> data 
integer_to_data(integer, data); integer -> data 
string_to_data(string,data); string -> data 
data_to_float(data,float*); data --> float 
data_to_integer(data,integer*); data --> integer 
data_to_string(data,string); data -> string 




void float_to_data(x, data) 
float x; 
char data[]; 

{ 

char x_str[MAX_FLOAT_SIZE]; 
sprintf(x_str, “%f’, x); 

sprintf(data, “R%04d%s”, strlen(x_str), x_str); 

} 


void integer_to_data(x, data) 
intx; 

char dataO; 

{ 

char x_str[MAX_INTEGER_SIZE]; 

sprmtf(x_str, “%d”, x); 

sprintf(data, “I%04d%s”, strlen(x_str), x_str); 

} 
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void string_to_data(str, data) 
char str[], data[]; 

{ 

sprintf(data, “C%04d%s”, strlen(str), str); 

} 


void data_to_float(data, px) 

chardataQ; 

float* px; 

{ 

char type; 
int size; 

sscanf(data,”%Ic%4d%f’, &tjT)e, ifesize, px); 


void data_to_integer(data, px) 
char dataO; 
int* px; 

{ 

char type; 
int size; 

sscanf(data,”%lc%4d%d”, &type, &size, px); 


void data_to_string(data, str) 
char datan, str[]; 

{ 

char type; 
int size; 

sscanf(data, “%lc%4d%s”, &type, &size, str); 


/ 

*3|!** + + *****************>|c********!|C**!f!**!(C************:t!**J(C****>fe********!|C*** 
y 

; Filename.: sun_iiis_commslc.c 

' ; 1. Created by Sehung Kwak 1/27/92 

; Use one socket for communication. 

» 

* ; *tac-to-ex comms-port* 1052 
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usage : start_iris (“<target_server>”); make connection 
put_iris_s (string); send string data 
put_iris_f (float); send floating point number 
put_iris_i (integer); send integer number 
get_iris_s (string); get string data 
get_iris_f (&float); get float data (ptr) 
get_iris_i (&integer); get integer data (ptr) 
stop_iris(); close communication 


This file needs convert.c and comm eluelc.c 



start_iris(host_name) 
char host_name[]; 

{ 

if (open_stream_c(host_name,TE_LOCAL_PORT)) 

retum(TRUE); 

else 

retum(FALSE); 

} 


stop_iris() 

{ 

retum(close_stream_c()); 

} 


int get_ack_c() 

( 

char buf[STR_BUFSIZE]; 
char str[10]; 

bzero(buf, sizeof buf); 

read_string_c(buf,STR_BUFSIZE); 

data_to_stiing(buf,str); 

if (!(strcmp(str,GET_DATA))) 

return 1; 

else 

return 0; 

} 

int send_ack_c() 

{ 


char bufTSTR_BUFSIZE]; 
strmg_to_data(GET_DATA,buf); 
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write_string_c(buf); 

} 


put_iris_s(str) 
char str[]; 

{ 

char buf[STR_BUFSIZE]; 
string_to_data(str,buf); 

write_string_c(buO; 

if (!(get_ack_c())) { 

printf(“Error: No acknowledgement \n”); 

} 

retum(TRUE); 

} 


put_iri s_f(num_f) 
float num_f; 

{ 

char buf[NUM_BUFSIZE]; 

float_to_data(num_f, buf); 
write_string_c(buf); 
if (!(get_ack_c())) { 

printf(“^or: No acknowledgement \n”); 

} 

retum(TRUE); 

} 

put_iris_i(num_i) 
int num_i; 

{ 

char buf[NUM_BUFSIZE]; 

integer_to_data(num_i, buf); 
write_string_c(buf); 
if (!(get_ack_cO)) { 

printf(“Error; No acknowledgement \n”); 

} 

retum(TRUE); 

} 


get_iris_s(str) 
char *str; 

{ 

char buf[STR_BUFSIZE]; 
read_string_c(buf, STR_BUFS IZE); 
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data_to_string(buf, str); 

send_ack_c(); 

retiirn(TRUE); 


get_iris_f(pf) 
float *pf; 

{ 

char buf[NlJM_BUFSIZE]; 

read_string_c(buf,NUM_BUFSIZE); 
data_to_float(buf, pf); 
send_ack_c(); 
retum(TRUE); 

} 

get_iTis_i(pi) 
int *pi; 

{ 

char buf[NUM_BUFSIZE]; 

read_string_c(buf,NUM_BUFSIZE); 
data_toJnteger(buf, pi); 
send_ack_c(); 
retum(TRUE); 

} 


/ 

*************************************)(!**!(!********************)(!********** 

J 

; Filename.: sun_iris_commsls.c 

; 1. Created by Sehung Kwak 12/3/92 
; Use one socket for communication, 

; *local-port* 1053 


usage: start_iris_s (); make connection 
put_iris_s_s (string); send string data 
put_iris_f_s (float); send floating point number 
put_iris_i_s (integer); send integer number 
get_iTis_s_s (string); get string data 
get_iris_f_s (&float); get float data (ptr) 
get_iris_i_s (&integer); get integer data (ptr) 
stop_iris_s(); close communication 
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; This file needs server.c and comm gluels.c 


start_iris_s() 

{ 

if (open_stream_s(ST_LOCAL_PORT)) 

retum(TRUE); 

else 

retum(FALSE); 

} 


stop_iris_s() 

{ 

retum(close_stream_s()); 

} 

put_iris_s_s(str) 
char str[]; 

{ 

char buf[STR_BUFSIZE]; 

string_to_data(str,buf); 
write_string_s(buf); 
force_out_s(); 
retum(TRUE); 

} 


put_iris_f_s(num_f) 
float num_f; 

{ 

char buf[NUM3UFSIZE]; 

float_to_data(num_f, buf); 
write_string_s(buf); 
force_out_s(); 
retum(TRUE); 

} 

put_iris_i_s(num_i) 
int num_i; 

{ 

char buf[NUM_BUFSIZE]; 

bzero(buf, sizeof buf); 
integer_to_data(num_i, buf); 
write_string_s(buf); 
force_out_s(); 
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} 


retum(TRUE); 


get_iris_s_s(str) 
char *str; 

{ 

char buf[STR_BUFSIZE]; 

read_string_s(buf, STR_B UFSIZE); 
data_to_string(buf, str); 
retum(TRUE); 

} 

get_iris_f_s(pf) 
float *pf; 

{ 

char buf[NUM_BUFSIZE]; 

read_string_s(buf,NUM_BUFSIZE); 
data_to_float(buf, pf); 
retum(TRUE); 

} 

get_iris_i_s(pi) 
int *pi; 

{ 

char buf[NUM_BUFSIZE]; 

bzero(buf, sizeof buf); 
read_string_s(buf,NlJM_BUFSI2E); 
data_to_integer(buf, pi); 
retum(TRUE); 

} 

get_from_strat_i() 

{ 

intx; 

get_iris_i_s(&x); 
retum(x); 

} 


/ 

****!(£********************}f!*******j(c*!|<********>(c3(C**>i(*********************** 

; The following are additional “access” routines used to link 
; sun_iiis_coninislc.c routines to Ada code without resorting to 
; passing of pointers. 

; 1. Geated by Ron Byrnes 11/19/92; revised 11/25/92 
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usage : start_comms(); avoids need to pass strings between Ada and C 
put_float(cmd); send floating point number 

get_float 0 ; extracts value from ptr to avoid passing addresses between Ada and C 
stop_comms(); maintains consistent labelling 


.!)t:(t******************!f!**************!|<**>(!****!)s*:*!>N*+*****sl!!i:**************y 


void start_comms() 

{ 

printf(“Starting comms with iris.NnXn”); 

start_iri s(“iri s 1”) J 

} 

void stop_comms() 

{ 

printf(“Stopping comms with iris.\n\n”); 
stop_iris(); 

} 

void put_float(cmd) 
float cmd; 

{ 

put_iris_f(cmd); 

} 

float get„float() 

{ 

float temp; 

get_iris_f(&temp); 

retum(temp); 

} 

void put_mode(cmd) 
int cmd; 

{ 

put_iiis_s(“TRANSIT”); /* At this time, sim has only one mode */ 


get_time() 

{ 

time_t now; 
now = time(NULL); 

printf(“%s%s\n”, “^e time is now = ctime(&now)); 


************************************************************************ 

*****s(e***!(c*********!|c**********j(!(f!*****j(e*3(c*************************:je****** 
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3. ADA-TO-C, C SIDE 


C*************************************=H****************************^ 

9 

; Filename.: comm_gluels.c 

y 

; This takes caie of socket stream commtmication interface. 

; Following functions are available. 

; An Iris running this program should be server. 

; 1. Created by Sehung Kwak 12/3/92 


usage ; open_stream_s (port_number); open write stream 

write_string_s (string); write string 

read_string_s (string, size); read string 

write_char_s (l6ngth_one_string); write character 

force_out_s (); output write buffer 

read_char_s (); read character 

close_stream_s (); close stream 


This file needs server.c. 


#define TRUE 1 
#define FALSE 0 
#define BUFSIZE 1024 


static int sock; 

static char sbuf[BUFSIZE]; 

static int sptr = 0; 

open_stream_s (port_num) 
long port_num; 

{ 

sock = start_server((int) port_num); 

bzero(sbuf, sizeof sbuf); /* initialize send buffer */ 
sptr = 0; f* initialize send buffer pointer */ 

if (sock >= 0) 

retum(TRUE); 

else 

retum(FALSE); 


lie 







} 


write_string_s (ps) 
char *ps; 

{ 

if (write(sock, ps, strlen(ps)) < 0) { 
perror(“Writing on stream socket”); 
retum(FALSE); 

} else 

retum(TRUE); 

} 


force_out_s () 

{ 

if (write_string_s(sbuf) = TRUE) { 
bzero(sbuf, sizeof sbuO; 
sptr = 0; 
retum(TRUE); 

} else 

retum(FALSE); 

) 


write_char_s (ps) 
char *ps; 

{ 


sbuf[sptr-f+]= *ps; 

if(sptr==BUFSlZE) 

force_out_s(); 


} 


read_string_s (str, size) 
char strQ; 
int size; 

{ 

if (read(sock, str, size) < 0) { 
peiTor(“Reading stream socket”); 
retum(FALSE); 

} else 

retum(TRUE); 

) 

char *read_char_s 0 

{ 


char onestr[4]; 
bzero(onestr, sizeof onestr); 
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if (read(sock, onestr, 1) < 0) { 
perror(“Reading stream socket”); 
retum(‘\fi’); 

} else 

retum(onestr); 


close_stream_s() 

{ 

if (close(sock) < 0) 

retum(FALSE); 

else 

retum(TRUE); 

} 


:(c :f; !<c)k Ik >k * Xi ** !ii * ij: 4s ****:<< if: 4: * )fi **>!< **:<<* 4! *>)<**** * >1= *** 4= ’i’***’K *’f’* 


Filename.: convert.c 

This program converts a number (float or integer) or a string 
to a communiction format and also records received data to 
a number(float or integer) or a string. 

Communication Format 

TXXXXDDDDDDDD,... 

T : type (one of I, R, C. i.e., integer, float, string) 

XXXX : data size in byte, filled with leading zeros 
DDD...: actual data (sequence of ASCII characters) 

example: 10003123 
aaaaaaaa 

TXXXXDDD 


1. Created by Sehung Kwak 1/27/92 

usage: float_to_data(fIoat, data); float --> data 
integer_to_data(integer, data); integer --> data 
string_to_data(string,data); string --> data 
data_to_float(data,float*); data -> float 
data_to_integer(data,integer*); data —> integer 
data_to_string(data,string); data --> string 


9K 4c 4c sic % % % % Sk % ^ ))e ^ >|c ^ 3fE % }fc 3|c 3k jfe a|c 3^ 4 e 3k 3f: 4c :|e :fe 3f: :fc :fc 4c 3fc % ^ 3fi 4c 9fe ale 3fE :fe:ic 


i 
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#include <stdio.h>; 

#define MAX_FLOAT_SIZE 30 
#define MAX_INTEGER„SIZE 30 


void float_to_data(x, data) 
float x; 
char data[]; 

{ 

char x_str[MAX_FLOAT_SIZE]; 
sprintf(x_str, “%f\ x); 

sprintf(data, “R%04d%s”, strlen(x_str), x_str); 

} 


void integer_to_data(x, data) 
int x; 

char data[]; 

{ 

char x_str[MAX^INTEGER_SIZE]; 

sprintf(x_str, “%d”, x); 

sprintf(data, “I%04d%s”, strlen(x_str), x_str); 

I 


void string_to_data(str, data) 
char str[], data[]; 

{ 

sprintf(data, “C%04d%s”, strlen(str), str); 

} 


void data_to_float(data, px) 
char data[]; 
float* px; 

{ 

char type; 
int size; 

sscanf(data,”%lc%4d%f&type, &size, px); 

} 

void data_to_integer(data, px) 
char data[]; 
int* px; 

{ 

char type; 
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} 


int size; 

sscanf(data,”%lc%4d%d”, &type, &size, px); 


void data_to_string(data, str) 
char datafl, strO; 

{ 

char type; 
int size; 

sscanf(data, “%lc%4d%s”, &type, &size, str); 


^ 3k 4:^ ^ :|c ^ 3(c 3}e :f:4:3^ 3k 4:4c ^ ^ ^ ^ ^ ^’k 4c ^ 3(c ak ^ 4^ 3{c sfe ^ 4; :fi: :(e % sf: sic ^ ;fe ^ :jc ^ 9^ 


Filename.; server.c 

This program creates a socket and returns the socket. 
The following function is available. 

1. Created by Sehung Kwak 12/3/91 


usage: start_server(port_number) 
; returns a socket 


sk 4c 4e 4c 3k 4c 4c 3k 4* % 4c % 3k 3k 3k 3k 4e 4c ak 3k ik 3k 3k 3k 3k ak 3k 3k 4c 3k 3k 4c ik 3k 4c 4c 3k 3k 3k 4s ak 3k 4c 3k 4c 3k 3k 4:% 3k 3k akak 3k 3k 3k 3k 3k 3k 3k 3k 3k ak 4c 3k 3k 4c 4c 4c j 


#include <sys/types.h> 
#include <sys/socketh> 
#include <netmet/in.h> 
#include <netdb.h> 
#include <stdio.h> 


/* 

Returns socket 
*1 

int start_server(port_number) 
int port_number; /* server port number */ 
{ 


int sock; 

Struct sockaddr_in server; 
int msgsock; 
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sock = socket(AF_INET, SOCK_STREAM, 0); 
if (sock < 0) { 

peiTor(“opening stream socket”); 
exit(l); 

} 

server. sin_family = AF_INET; 
server. sin_addr.s_addr = INADDR_ANY; 
server. sin_port = port_number; 
if (bind(sock, (struct sockaddr *)&server, 
sizeof server) < 0) { 
perror(“binding stream socket”); 
exit(l); 

} 

listen(sock,5); 

msgsock = accept(sock, 

(struct sockaddr *)0, (int *)0); 
if (msgsock = -1) { 
perror(“accept”); 
exit(2); 

} else 

retum(msgsock); 


*****!(! !H*!(!*****5|!****************!(!*Jt:>f;**!(!**Jfc*sK****>|(***Jf!***J(e***>Ic****:)c*:jc5(:**** 

Filename.......; sun_ms_commsls.c 

1. Created by Sehung Kwak 12/3/92 
Use one socket for communication. 

*local-port* 1052 


usage : start_iris_s (); make connection 
put_iris_s_s (string); send string data 
put_iris_f_s (float); send floating point number 
put_iris_i_s (integer); send integer number 
get_iris_s_s (string); get string data 
get_ms_f_s (&float); get float data (ptr) 
get_iris_i_s (&integer); get integer data (ptr) 
stop_ms_s(); close communication 




This file needs server.c and comm_gluels.c 

********************Jtl*jfC**3f!********j|c*****3(c************j((**3^;,t****j^**^^3jjj^^^ 
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#mclude <stdio.h> 
#include <string.h> 


#define TRUE 1 
#define FALSE 0 
#define LOCAL.PORT 1052 
#define STR_BUFSIZE 1024 
#define NUM_BUFSIZE 30 
#define GET_DATA “get_data” 

start_ms_s() 

{ 

printf(“Listening for Tactical level...ViVi”); 
if (open_stream_s(LOCAL_PORT)) 
retum(TRUE); 
else 

retum(FALSE); 

} 


stop_iris_sO 

{ 

retum(close_stream_s()); 

} 


int get_ack_s() 

{ 

char buf[STR_BUFSIZE]; 
char str[10]; 

bzero(buf, sizeof buf); 

read_string_s(buf,S'ITl_BUFSIZE); 

data_to_string(buf,str); 

if (!(strcmp(str,GET_DATA))) 

return 1; 

else 

return 0; 

} 

int send_ack_sO 

{ 

char buf[STR_BUFSIZE]; 

string_to_data(GET_D AT A,buf); 
write_string_s(buf); 

} 
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put_iris_s_s(str) 
char str[]; 

{ 

char buf[STR_BUFSIZE]; 

string_to_data( str, buf); 
write_stxing_s(buf); 
if (l(get_ack_s())) { 

printf(“Error: No acknowledgement \n”); 

} 

return(TRUE); 

} 


put_iris_f_s(num_f) 
float num_f; 

{ 

char buf[NUM_BUFSIZE]; 

float_to_data(num_f, buf); 
write_string_s(buf); 
if (!{get_ack_s())) { 

printf(“Error; No acknowledgement \n”); 

} 

retum(TRUE); 

} 

put_iris_i_s(num_i) 
int num_i; 

{ 

char buf[NUM_BUFSIZE]; 

integer_to_data(num_i, buf); 
WTite_string_s(buf); 
if (!(get_ack_s())) { 

printf{“Error: No acknowledgement \n”); 

} 

retum(TRUE); 

} 


get_iris_s_s(str) 
char *str; 

{ 

char buf[STR_BUFSIZE]; 

read_string_s(buf,STR_BUFSI2^); 
data_to_string(buf, str); 
send_ack_s(); 
retum(TRUE); 

} 
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get_iris_f_s(pf) 
float *pf; 

{ 

char buf[NUM_BUFSIZE]; 

read_string_s(buf,NUM_BUFSIZE); 
data_to_float(buf, pf); 
send_ack_s(); 
retum(TRUE); 

} 

get_iris_i_s(pi) 
int *pi; 

{ 

char buf[NUM_BUFSIZE]; 

read_string_s(buf,NUM_BUFSIZE); 
data_to_integer(buf, pi); 
send_ack_s(); 
retum(TRUE); 


get_from_strat_i() 

{ 

intx; 

get_iris_i_s(&x); 

retum(x); 

} 
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APPENDIX D. GLOSSARY OF TERMINOLOGY FOR AUTONOMOUS 
VEHICLE SOFTWARE ARCHITECTURES 


Autonomous Vehicle: a self-contained mobile robot with the capacity to sense a dynamic 
and unstructured environment, plan an intelligent response to that input, and act in a way 
that is compatible with the accomplishment of a mission without human intervention. 

Behavior: an algorithm designed specifically to generate the numeric input required by a 
feedback control system which will, in turn, produce a change in the underlying physical 
plant consistent with the desired primitive goal which activated the behavior. The term task 
is a frequently used synonym. 

Doctrine: the part of the RBM Strategic level containing the logic required to solve prob¬ 
lems not unique to the particular mission at hand. Doctrine is in general vehicle dependent. 

Execution Level: the lowest level of the Rational Behavior Model containing all the soft¬ 
ware required to meet hard real-time deadlines while ensuring basic vehicle stability and 
safety. 

Goal: a result toward which effort, provided by an external entity, is directed. The problem, 
prior to decomposition, is the root goal. The set of goals not further decomposed are called 
primitive goals, and all other subgoals are called intermediate goals. 

Goal Tree: a graphical representation of AND/OR goal decomposition, with the root node 
representing the root goal, the leaf nodes representing the primitive goals, all other nodes 
representing intermediate goals subject to further decomposition, and the connecting arcs 
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representing the logical relationship between subgoals and the goal from which they were 
decomposed. 

Layer of Control: the realization of a single behavior or competence of the underl 5 dng sys¬ 
tem. 

Level of Control: a distinct set of computational entities characterized by a shared concep¬ 
tual abstraction, of which temporal, spatial, and command hierarchies are the most com¬ 
mon. 

Mission Model: a database comprising the information necessary to uniquely identify each 
segment or phase of the mission and the terminating conditions for each phase. 

Mission Specification: the part of the RBM Strategic level containing the rule set embody¬ 
ing mission specific knowledge. 

Problem Decomposition: the successive simplification of a root goal, resulting in interme¬ 
diate and primitive goals which may be placed in a tree structure to represent the orderly 
search for a problem solution. 

Rational Behavior Model-Backward (RBM-B): a form of RBM characterized by a back¬ 
ward-chaining inference mechanism at the strategic level employing goal decomposition 
and an AND/OR goal tree as the basis for its search. 

Rational Behavior Model-Forward (RBM-F): a form of RBM characterized by a forward- 
chaining inference mechanism at the Strategic level employing a state transition diagram 
to organize the sequence of allowable state transitions. 
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Software Architecture: a structural plan encompassing the conceptual design and organiza¬ 
tion of software. The architecture includes, but is not limited to, a description of the abstrac¬ 
tion mechanisms, division of responsibility, and specification of external interfaces through 
which the software entities communicate with each other and the external world. Each soft¬ 
ware entity, also called a module, is an independent conceptual unit within a software sys¬ 
tem. 

State Transition Diagram with Path Priorities: models the time-dependent behavior of a 
system containing state transition conditions which may not be mutually exclusive. Con¬ 
flicts in determining the next state are resolved through the use of pre-assigned, numerical 
path priorities. 

World Model: the set of data reflecting the characteristics of the environment external to 
the vehicle and upon which the control software bases its decisions. 


♦ 
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